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pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
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Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet 
converged Services and Protocols for Advanced Networking (TISPAN). 

The present document is part 2 of a multi-part deliverable covering the IMS NNI Interworking Test Specifications, as 
identified below: 

Part 1 : "Test Purposes for IMS NNI Interworking"; 

Part 2: "Test Descriptions for IMS NNI Interworking". 
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Scope 



The present document specifies interoperability Test descriptions (TDs) for IMS NNI interworking for the IP 
Multimedia Call Control Protocol based on Stage 3 Session Initiation Protocol (SIP) and Session Description Protocol 
(SDP) standard, TS 124 229 [1]. TDs have been specified on the basis of the test purposes (TPs) and test suite structure 
(TSS) presented in [2]. TP fragments presented in the present document as part of TDs are defined using the TPLan 
notation (ES 202 553 [5]). TDs have been written based on the test specification framework described in TS 102 351 [3] 
and the interoperability testing methodology defined in TS 102 237-1 [4], i.e. interoperability testing with a 
conformance relation. 

The scope of these test descriptions is not to cover all requirements specified in TS 124 229 [1]. It has been reduced to 
cover only requirements which relate to basic IMS call functionality for a minimal interworking IMS CN configuration, 
i.e. based on a P-CSCF, S-CSCF, I-CSCF, and HSS. Therefore, assessment of, e.g. IMS roaming, topology hiding, etc. 
at the NNI are not addressed in this test purpose specification. TDs have been only specified for requirements that are 
observable at the interface between two separate minimal IMS CN implementations, i.e. IMS NNI. 

NOTE: Requirements which can only be observed at the interface between UE and IMS CN, i.e. home P-CSCF, 
are explicitly not within the scope of the present document. The latter requirements have been dealt with 
from a UE and conformance perspective in TS 134 229 [6]. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, 
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the 
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the 
method of access to the referenced document and the full network address, with the same punctuation and use of upper 
case and lower case letters. 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 124 229 (V6.13.0): "Digital cellular telecommunications system (Phase 2+); Universal 

Mobile Telecommunications System (UMTS); Internet Protocol (IP) multimedia call control 
protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); 
Stage 3 (3GPP TS 124 229 version 6.13.0 Release 6)". 
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[2] ETSI TS 186 01 1-1: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IMS NNI Interworking Test Specifications; Part 1: Test 
purposes for IMS NNI Interworking". 

[3] ETSI TS 102 35 1 : "Methods for Testing and Specification (MTS); Internet Protocol Testing (IPT); 

IPv6 Testing: Methodology and Framework". 

[4] ETSI TS 102 237-1: "Telecommunications and Internet Protocol Harmonization Over Networks 

(TIPHON) Release 4; Interoperability test methods and approaches; Part 1: Generic approach to 
interoperability testing". 

[5] ETSI ES 202 553: "Methods for Testing and Specification (MTS); TPLan: A notation for 

expressing Test purposes". 

[6] ETSI TS 134 229 (V6.0.0): "Universal Mobile Telecommunications System (UMTS); Internet 

Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and 
Session Description Protocol (SDP); Part 2: Implementation Conformance Statement (ICS) 
specification (3GPP TS 34.229-2 version 6.0.0 Release 6)". 

[7] ETSI TS 123 228 (V6.15.0): "Digital cellular telecommunications system (Phase 2+); Universal 

Mobile Telecommunications System (UMTS); IP Multimedia Subsystem (IMS); Stage 2 
(3GPP TS 23.228 version 6. 15.0 Release 6)". 

[8] ETSI TS 133 203 (V6.10.0): "Digital cellular telecommunications system (Phase 2+); Universal 

Mobile Telecommunications System (UMTS); 3G security; Access security for IP -based services 
(3GPP TS 33.203 version 6. 10.0 Release 6)". 

[9] Void. 

[10] Void. 

[11] ETSI TS 123 060 (V6.15.0): "Digital cellular telecommunications system (Phase 2+); Universal 

Mobile Telecommunications System (UMTS); General Packet Radio Service (GPRS); Service 
description; Stage 2 (3GPP TS 23.060 version 6.15.0 Release 6)". 

[12] ETSI TS 127 060 (V6.0.0): "Digital cellular telecommunications system (Phase 2+); Universal 

Mobile Telecommunications System (UMTS); Packet domain; Mobile Station (MS) supporting 
Packet Switched services (3GPP TS 27.060 version 6.0.0 Release 6)". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[13] ETSI TR 133 978 (V6.6.0): "Universal Mobile Telecommunications System (UMTS); Security 

aspects of early IP Multimedia Subsystem (IMS) (3GPP TR 33.978 version 6.6.0 Release 6)". 

[14] ETSI TR 123 981 (V6.4.0): "Universal Mobile Telecommunications System (UMTS); 

Interworking aspects and migration scenarios for IPv4-based IP Multimedia Subsystem (IMS) 
implementations (3GPP TR 23.981 version 6.4.0 Release 6)". 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

3GPP 3 r Generation Partnership Project 

AS (IMS) Application Server 

CF (Test) ConFiguration 

CFW Call FloW 

CN Core Network 

CSCF Call Session Control Function 
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DHCP Dynamic Host Configuration Protocol 

DNS Domain Name System 

HSS Home Subscriber Server 

I-CSCF Interrogating CSCF 

IMS IP Multimedia Subsystem 

IOI Inter Operator Identifier 

IP Internet Protocol 

NNI Network-to-Network Interface 

PCO Point of Control and Observation 

P-CSCF Proxy CSCF 

PO POstamble 

PR PReamble 

PSTN Public Switched Telephone Network 

RQ ReQuirement 

S-CSCF Serving CSCF 

SIP Session Initiation Protocol 

SDP Session Description Protocol 

SUT System Under Test 

TISPAN Telecommunications and Internet converged Services and Protocols for Advanced Networking 

TB Test Body 

TD Test Description 

TP Test Purpose 

TPLan Test purpose Notation 

TSS Test Suite Structure 

UC Use Case 

UE User Equipment 

URI Uniform Record Identifier 

VoIP Voice over Internet Protocol 

XML Extensible Markup Language 



IMS NNI Interoperability Test Specification 



4.1 



Introduction 



The IMS NNI Interoperability Test descriptions (TDs) defined in the following clauses are derived from the Test 
purposes (TPs) specified in [1]. 



4.2 Test prerequisites 

4.2.1 IP version 

These test specifications are based on the use of IPv4 for SIP message transport throughout all IMS nodes [14]. 

4.2.2 IP bearer establishment 

4.2.2.1 3GPP 

3GPP bearer establishment procedures imply the creation of a PDP context over GPRS [11] and [12]. 

4.2.3 Authentication and security 



4.2.3.1 



3GPP 



The current test specification supports standard 3GPP security, namely full IMS [8], early IMS [13] and optionally 
allows SIP Digest authentication without key agreement and null authentication. 



ETSI 



ETSI TS 186 011-2 V1.0.0 (2008-04) 



4.2.4 Registration and subscription 



4.2.4.1 SIP call flow 

This clause describes the registration call flow under the authentication and security scope described in clause 4.2.2. 
Depending on the security and authentication method used, the registration steps are: 
1 . All: The UE establishes an IP bearer as required by its specific access network. 

All: Optional P-CSCF address discovery using the DHCP procedure. 

All: The UE initiates IMS registration. IMS waits for the UE to send an initial REGISTER request. 



2. 
3. 
4. 



Full IMS, SIP Digest: The IMS responds to the initial REGISTER request with a valid 401 unauthorized 
response. 



5. Full IMS: The IMS and UE set up a temporary set of security associations. 

6. Full IMS, SIP Digest: UE sends another REGISTER request (over the security associations for Full IMS). 

7. All: The IMS responds to the REGISTER request with valid 200 OK responses (sent over the same temporary 
set of security associations that the UE used for sending the REGISTER request for Full IMS). 

8. All: The IMS waits for the UE to send a SUBSCRIBE request (over the newly established security association 
for Full IMS). 

9. All: The IMS responds to the SUBSCRIBE request with a valid 200 OK response. 

10. All: The IMS sends a valid NOTIFY request for the subscribed registration event package. 

1 1 . All: The IMS waits for the UE to respond to the NOTIFY with a 200 OK response. 
Expected sequence: 



Step 


Direction 


Message 


Comment 


UE | IMS 


2 


^^ 




Optional P-CSCF address discovery using DHCP 
procedures for IPv4. 


3 


^ 


REGISTER 


The UE sends initial registration for IMS services. 


4 


^ 


401 Unauthorized 


Full IMS, SIP Digest: The IMS responds with a valid 
authentication challenge and security mechanisms 
supported by the network. 


5 


^ 


REGISTER 


Full IMS, SIP Digest: The UE completes the 
security negotiation procedures (sets up a 
temporary set of security associations for Full IMS) 
and sends another REGISTER with authentication 
credentials. 


6 


<- 


200 OK 


The IMS responds with 200 OK. 


7 


-> 


SUBSCRIBE 


The UE subscribes to its registration event 
package. 


8 


<- 


200 OK 


The IMS responds with 200 OK. 


9 


^ 


NOTIFY 


The IMS sends initial NOTIFY for registration event 
package, containing full registration state 
information for the registered public user identity in 
the XML body. 


10 


^ 


200 OK 


The UE responds with 200 OK. 



4.2.5 Supported options 



4.2.5.1 



Security 



"Early IMS" is the default security configuration in all test descriptions. Optional support for sec-agree when full IMS 
security is used. Tests may be executed with full IMS security if all required IMS nodes support it. 
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4.2.5.2 Signalling compression 



"No sigcomp" is the default signalling configuration in all test descriptions. Tests may be executed with signalling 
compression if the required nodes support it. 

4.2.5.3 Preconditions 

"No precondition" is the default SDP configuration in all test descriptions. Tests may be executed with SDP 
preconditions if the required nodes support it. 

4.2.5.4 Reliable provisional responses 

Reliable provisional responses (lOOrel) are the default signalling configuration in all test descriptions. 

4.2.5.5 Forking 

Not applicable in the current test specification. However, support for forking is a requirement of the IMS specification. 

4.3 Test infrastructure 

In these clauses we define the involvement of the various IMS nodes specifically as they pertain to NNI testing. The 
configuration of the nodes is described. Points of control and observation are identified and static test configurations are 
described. The Mw interface is the interface under observation for NNI interoperability testing. 

4.3.1 Core IMS nodes 

Because the current testing scope excludes IMS roaming and border control functionality, P-CSCF, S-CSCF, I-CSCF, 
and HSS are considered to be within a "black box" for testing purposes. We refer to this System Under Test (SUT) as 
"the minimal IMS". Interfaces within the IMS are considered internal and not observable for testing purposes. The use 
cases and test descriptions described below may be run with IMS roaming without modifications. However, no test 
descriptions are available that validate the operation of the Mw interface between the P-CSCF and S-CSCF as an NNI 
interface. 

4.3.1.1 P-CSCF 

4.3.1 .1.1 Relevant interfaces 

The P-CSCF constitutes the point of entry for UE signalling into the IMS core. The Gm interface between the P-CSCF 
and the UE is used as a point of control and observation (PCO) for NNI interoperability testing purposes. Although 
considered as internal and not explicitly involved in current NNI test configurations which exclude IMS roaming, it is 
recommended that the Mw interface between the P-CSCF and S-CSCF be exposed/available for troubleshooting 
purposes. 

4.3.1.1.2 Node configuration 

The P-CSCF should be configured to support the pre-requisites outlined in clause 4.2. 

4.3.1.2 S-CSCF 

4.3.1.2.1 Relevant interfaces 

The S-CSCF is the core IMS node delivering IMS services to subscribers. The Mw interface between the S-CSCF and 
either I- or S-CSCF in another domain is used as a point of observation against which NNI interoperability tests are 
validated. The Mw interfaces between I- and S-CSCFs within the same network are considered as internal IMS 
interfaces. Although considered as internal and not explicitly involved in current NNI test configurations which exclude 
IMS roaming, it is recommended that the Mw interface between the P-CSCF and S-CSCF be exposed for 
troubleshooting purposes. 
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4.3.1.2.2 



Node configuration 



The S-CSCF should be configured to support the pre-requisites outlined in clause 4.2. When applicable based on the 
specific configuration, the S-CSCF must be provisioned to support required Application Servers (AS) as trusted nodes. 



4.3.1.3 



HSS 



4.3.1.3.1 



Relevant interfaces 



The HSS constitutes the repository for IMS subscriber information. The Cx interface between the HSS and the S-CSCF 
and/or I-CSCF is considered an internal IMS interface. 



4.3.1.3.2 



Node configuration 



The HSS should be configured within the IMS to interact with CSCFs as required using DIAMETER Cx interfaces. For 
the purpose of this test specification, "ims_a.net" refers to the domain served by "IMS_A" and "ims_b.net" refers to the 
domain served by "IMS_B". Users should be provisioned to match the sample profiles listed in table 1. All public 
identities belong to the same implicitly registered set. 

Table 1 : HSS sample user profiles 



IMS 
Domain 


Private Identity 


Public Identity 1 


Public Identity 
2 


Default 
Public 
Identity 


Filter criteria 


ims_a.net 


use r_a1_priv@ims_a. 
net 


sip:use r_a1_pub@ims_ 
a.net 


na 


1 


na 


ims_a.net 


use r_a2_priv@ims_a. 
net 


sip:user_a2_pub@ims_ 
a.net 


tel:+336333482 
73 


1 


na 


ims_a.net 


use r_a3_priv@ims_a. 
net 


sip:user_a3_pub@ims_ 
a.net 


tel:+336333482 
74 


2 


na 


ims_a.net 


use r_a4_priv@ims_a. 
net 


sip:user_a4_pub@ims_ 
a.net 


na 


1 


terminating unregistered/INVIT 
E/ SESSION_TERMINATED/ 
as al.ims a.net 


ims_a.net 


use r_a5_priv@ims_a. 
net 


sip:user_a5_pub@ims_ 
a.net 


na 


1 




ims_b.net 


use r_b1_priv@ims_a. 
net 


sip:use r_b1_pub@ims_ 
a.net 


na 


1 




ims_b.net 


use r_b2_priv@ims_a. 
net 


sip:user_b2_pub@ims_ 
a.net 


tel:+447444593 
84 


1 




ims_b.net 


use r_b3_priv@ims_a. 
net 


sip:user_b3_pub@ims_ 
a.net 


tel:+447444593 
85 


2 




ims_b.net 


use r_b4_priv@ims_a. 
net 


sip:user_b4_pub@ims_ 
a.net 


na 


1 


terminating unregistered/INVIT 
E/ SESSION_TERMINATED/ 
as bl.ims b.net 


ims_b.net 


use r_b5_priv@ims_a. 
net 


sip:user_b5_pub@ims_ 
a.net 


na 


1 





4.3.2 External IMS nodes 



4.3.2.1 



UE 



4.3.2.1.1 



Relevant interfaces 



The UE is considered to act as a stimulus node in this test specification. The Gm interface between the P-CSCF and the 
UE is used as a point of control and observation (PCO) for NNI interoperability tests. 

4.3.2.1.2 Node configuration 

The UE should be configured to support the pre-requisites outlined in clause 4.2. 
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4.3.2.2 AS 

4.3.2.2.1 Relevant interfaces 

The application server (AS) is considered to act as a stimulus node in this test specification. The ISC interface between 
the S-CSCF and the AS is used as a point of control and observation (PCO) for NNI interoperability tests. 

4.3.2.2.2 Node configuration 

The AS should be configured to support the pre-requisites outlined in clause 4.2. 

4.3.3 Supporting IMS nodes 
4.3.3.1 DNS 

4.3.3.1.1 Relevant interfaces 

The Domain Name Service (DNS) is considered as a supporting entity in this test specification. 

4.3.3.1.2 Node configuration 

DNS should be configured for appropriate resource record handling as required to support proper resolution of all SIP 
URIs in Request URIs and Route headers. In addition, DNS must support ENUM functionality in order to resolve Tel 
URIs into SIP URIs. 



4.3.4 Test configurations 



The following architectural test configurations are referenced in the IMS NNI interoperability TDs in the present 
document. They are intended to give a general rather than a specific view of the required IMS SUT(s) connectivity and 
associated UE(s), AS(s), and DNS(s). 

The following guidelines are used to describe the test configurations: 

• Named based convention defined in TS 123 228 [7] clause 5.5.1. 

• Reuse the following abbreviations: 

SSI: Different network operators performing origination and termination. 

M02: Mobile origination, home. The "Originating Network" of S-S#l is 
therefore the home network. 

ASO: Application Server origination. The" Originating Network" of S-S#l is 
the home network. 

MT2: Mobile termination, located in home service area. The "Terminating 
Network" of S-S#l is the home network. 

AST4: Termination at Application Server based on service logic. 

• Exclude PSTN, non-IMS endpoints and IMS roaming since these are out of scope. 

• Further differentiate IMS NNI observation points based on: 

IN: initial request/response for a dialog. 

SU: subsequent requests/responses in a dialog. 

ST: standalone requests/response. 
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and indicate: 

observable interfaces as a solid line, 
non-observable interfaces as dashed lines. 
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Precondition: 

Different network operators performing origination and termination (SS1 ), UEA in Home network A 

(M02), UE_A registered, neither AS norTHIG nor IMS-ALG involved 
Test configuration for: 

Unsuccessful initial requests and responses from UEA 
Example: 

Initial INVITE in IMS VoIP voice call from UEA to non-existing user 

Figure 1:CF_M02-SS1 
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Precondition: 

Different network operators performing origination and termination (SS1 ), UEA in Home network A 

(M02), UE_B in Home network B (MT2), both UEs registered, neither AS nor THIG nor IMS-ALG 

involved, in SU case dialog initiated between UEA and UEB 
Test configuration for: 

Initial (IN) and Subsequent (SU) requests and responses between UEA and UEB 
Example: 

IN: Initial INVITE in IMS VoIP voice call from UE_A to UE_B 

SU: BYE request, UE_B terminates IMS VoIP call towards UE_B 

Figure 2: CF_M02-SS1-MT2 
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Precondition. 

Different nefrvork operators performing origination and termination (SS1), UE_A in Home nefrvork A 

(M02), UE_B in Home network B (MT2), only UE_A registered, neither AS nor THIG nor IMS-ALG 

involved, in SU case dialog initiated between UE_A and UE_B 
Test configuration for: 

Unsuccessful initial reguests and responses from UE_A 
Example: 

Initial INVITE in IMS VoIP voice call from UE A 



Figure 3: CF_M02-SS1-MT2b 



UE 
A 



Gm 



* 



PCO 



IMS A 



P-CSCF 



HSS 





S-CSCF 








l-CSCF 
V 



Mw 




PO 



S-CSCF 



l-CSCF 




PCO 



Precondition: 

Different network operators performing origination and termination (SS1), UE_A in Home network A 
(M02), UE_B in Home network B (MT2), both UEs registered, DNS server involved in networkB 
neither AS nor THIG nor IMS-ALG involved, in SU case dialog initiated between UE_A and UE_B 

Test configuration for: 

Initial requests and responses between UE_A and UE_B 

Example: 

Initial INVITE in IMS VoIP voice call from UE A 



Figure 4: CF_M02-SS1-MT2c 
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Precondition: 

Different network operators performing origination and termination (SS1), UE_A in Home network A 

(MO#2), UE_B in Home network B (MT#2), AS_B discovered based on service logic in Home network 

B (AST#4), only UE_A registered, in SU case dialog initiated between UE_A and AS_B, neither THIG 

nor IMS-ALG involved 
Test configuration for: 

Initial (IN) and Subsequent (SU) requests and responses between UE_A and AS_B 
Example: 

IN. Initial INVITE, IMS VoIP voice call from UE_A forwarded to AS_B as a result of filter criteria. ASB 
acts as routing AS 

SU: BYE request, UE_A terminates IMS VoIP voice call towards AS_B 



Figures: CF_M02-SS1-MT2-AST4 




AS 
B 



Precondition: 

Different network operators performing origination and termination (SS1), UE_A in Home network A 
(MO#2), UE_B in Home network B (MT#2) AS_B discovered based on service logic in Home network 
B (AST#4) only UE_A registered, AS_B not responding, neither THIG nor IMS-ALG involved 

Test configuration for: 

Initial (IN) and Subsequent (SU) requests and responses between UE_A and AS_B 

Example: 

IN: Unsuccessful initial INVITE, IMS VoIP voice call from UE_A forwarded to AS_B as a result of 
filter criteria but no response 



Figure 6: CF_M02-SS1-MT2-AST4b 



4.4 Test descriptions 



Test descriptions (TDs) are provided below. For each TD, one generic use case forms the basis of the test sequence 
which presented in clause 4.5.2 of the present document. Each test sequence step includes also a reference to a specific 
step within the SIP call flow steps of the generic use case. Whereas test preamble (PR) and postamble (PO) call flow 
steps are only referenced in test descriptions, the call flow steps for the test body (TB) are repeated after each TD and 
include any modifications necessary to the generic use case call flow. In test body call flows steps that are associated 
with user interactions are shown shaded and steps which have pass criteria are associated with are shown in bold. 



ETSI 



17 



ETSI TS 186 011-2 V1.0.0 (2008-04) 



4.4.1 General capabilities 

4.4.1 .1 IMS CN components shall support SIP messages greater than 1 500 bytes 



Test description 


Identifier: 


TD IMS 0001 


Summary: 


IMS CN components shall support SIP messages greater than 1 500 bytes 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 4002 01 


TS 124 229 [1] clause 4.2A paragraph 1 


Use case: 


UC 05 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 100rel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UE_A, UE_B registered as per clause 4.2.3 

• UE A, UE B registered public identities are SIP URIs only 


Test sequence: 


Step 




1 PR 


UE A is requested to send a MESSAGE with 2 000 byte file to UE B (prior to 
CFW step 1 ) 


2 TB 


Verify that message delivery is attempted over TCP (CFW step 2) 


3 TB 


Verify that UE_B receives MESSAGE with 2 000 byte file (prior to CFW 
step 4) 


Pass criteria: 


Check 




1 


TP_IMS_4002_01 in CFW step 2 (MESSAGE): 
ensure that { 
when { UE_A sends MESSAGE to UE_B 

containing a Message Body bigger than 1 500 bytes } 
then { IMS_B receives the MESSAGE 

containing a Message_Body bigger than 1 500 bytes 
and 

UE B receives MESSAGE 
} 
} 



The expected test body call flow sequence is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 
M 

s 

A 


1 
M 

s 

B 


U 

E 
B 


1 




^ 








MESSAGE 


UE A sends MESSAGE to IMS A 


2 






^ 






MESSAGE 


IMS A sends MESSAGE to IMS B 


3 








^ 




MESSAGE 


IMS A sends MESSAGE to UE B 


4 








^ 




200 OK 


UE B sends 200 OK to IMS B 


5 






^ 






200 OK 


IMS B sends 200 OK to IMS A 


6 




^ 








200 OK 


IMS A sends 200 OK to UE A 
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4.4.2 Initial dialog or standalone request procedures 



4.4.2.1 



Standalone request procedures 



4.4.2.1.1 



Standalone MESSAGE request procedure 



Test description 


Identifier: 


TD IMS 0002 


Summary: 


Standalone MESSAGE request procedures 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5050 03 




TP IMS 5061 02 


TS 124 229 [1] clause 5.2.6.4 paragraph 89 


TP IMS 5097 06 


TS 124 229 [1] clause 5.4.3.2 paragraph 1 


TP IMS 5117 02 


TS 124 229 [1] clause 5.4.3.3 paragraph 49 


TP IMS 5118 01 


TS 124 229 [1] clause 5.4.3.3 paragraph 54 


Use case 


UC 05 


reference: 




Pre-test 


• Static configuration as per clause 4.3 


conditions: 


• UE_A, UE_B support 100rel, no SDP preconditions 




• UE A, UE B have no filter criteria defined in HSS 




• UE A, UE B IP bearers established as per clause 4.2.1 




• UE_A, UE_B registered as per clause 4.2.3 




• UE A, UE B registered public identities are SIP URIs only 


Test sequence: 


Step 




1 PR 


UE_A is requested to send a MESSAGE from UE_A to UE_B (prior to CFW 






step 1 ) 


2 TB 


Verify that UE_B gets the MESSAGE (prior to CFW step 4) 


Pass criteria: 


Check 




1 


TP_IMS_5050_03 in CFW step 2 (MESSAGE): 






ensure that { 






when { UE A sends MESSAGE to UE B } 






then { IMS B receives MESSAGE 






not containing P-Preferred-ldentity_header and 






containing P-Asserted-ldentity_header 






containing an address of UE A 






and 






containing the P-Charging-Vector_header 






containing icid_parameter 






and 






UE B receives MESSAGE 
} 
} 


2 


TP_IMS_5061_02 in CFW step 5 (200 OK): 






ensure that { 






when { UEB sends a 2xx_response from UEA } 






then { IMS_A receives the 2xx_response 






not containing P-Preferred-ldentity_header and 






containing P-Asserted-ldentity_header 






containing the address 'sent in P-Called_Party-ID header of the 






standalone request' 






and 






UE A receives the 2xx response 

} 
} 


3 


TP_IMS_5097_06 in CFW step 2 (MESSAGE): 






ensure that { 






when { UE A sends a MESSAGE to UE B } 






then { IMS B receives the MESSAGE 






containing a P-Charging-Vector_header 






containing a icid_parameter 






and 






UE B receives the MESSAGE} 
} 


4 


TP_IMS_5097_07 in CFW step 2 (MESSAGE): 
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Test description 



ensure that { 
when { UE_A sends MESSAGE to UE_B } 
then { IMS_B receives the MESSAGE 

containing a topmost Record-Route_header 

indicating the originating S-CSCF_SIP_URI and 
containing a P-Charging-Vector_header 
(containing a orig-ioijparameter 

indicating ioi of IMS_A and 
not containing a access-network-charging-info_parameter) 



and 



L 



not containing a P-Access-Network-lnfo_header 
and 
UE_B receives the MESSAGE} 



TP_IMS_51 17_02 in CFW step 5 (200 OK) 
ensure that { 

when { UE 

then { IMS'_ 



and 



B sends 2xx_response to UEA } 
A receives the 2xx_response 
containing a P-Charging-Vector_header 
not containing a access-network-charging-info_parameter 



L 



not containing a P-Access-Network-lnfo_header 
and 
UEA receives the 2xx_response } 



TP_IMS_51 18_01 in CFW step 5 (200 OK): 
ensure that { 
when { UEB sends 200_response to UEA } 
then { IMS_A receives the 200_response 

containing a P-Charging-Vector_header 
containing a orig-ioijparameter 

indicating ioi of IMS_A and 
containing a term-ioi_parameter 
indicating ioi of IMS_B 
and 
UEA receives the 200_response } 



The expected test body call flow sequence is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


1 




^ 








MESSAGE 


UE A sends MESSAGE to IMS A 


2 






^ 






MESSAGE 


IMS A sends MESSAGE to IMS B 


3 








^ 




MESSAGE 


IMS A sends MESSAGE to UE B 


4 








^ 




200 OK 


UE B sends 200 OK to IMS B 


5 






<r 






200 OK 


IMS B sends 200 OK to IMS A 


6 




^ 








200 OK 


IMS A sends 200 OK to UE A 



ETSI 



20 



ETSI TS 186 011-2 V1.0.0 (2008-04) 



4.4.2.1.2 



Standalone MESSAGE request procedure with implicit Tel URI 



Test description 


Identifier: 


TD IMS 0003 


Summary: 


Standalone MESSAGE request procedures with implicit Tel URI 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5097 08 


TS 124 229 [1] clause 5.4.3.2 paragraph 1 


TP IMS 5117 04 


TS 124 229 [1] clause 5.4.3.3 paragraph 49 


Use case ref.: 


UC 05 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 100rel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UE_A, UE_B registered as per clause 4.2.3 

• UE_A, UE_B implicitly registered public identities include SIP and Tel URIs 

• UE A, UE B default public identity is a SIP URI 


Test sequence: 


Step 




1 PR 


UE_A is requested to send a MESSAGE from UE_A to UE_B (prior to CFW 
step 1 ) 


2 TB 


Verify that UE_B gets the MESSAGE (prior to CFW step 4) 


Pass criteria: 


Check 




1 


TP_IMS_5097_08 in CFW step 2 (MESSAGE): 
ensure that { 
when { UE_A sends MESSAGE to UE_B 

not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
not indicating a Tel_URI} 
then { IMS_B receives the MESSAGE 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity and 
containing a P-Asserted-ldentity_header 
indicating a Tel_URI 
and 

UE B receives the MESSAGE} 
} 






TP_IMS_51 17_04 in CFW step 5 (200 OK): 
ensure that { 
when { UEB sends 2xx_response to UEA 

not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
not indicating a Tel_URI} 
then { IMS_A receives the 2xx_response 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity and 
containing a P-Asserted-ldentity_header 
indicating a Tel_URI 
and 

UE A receives the 2xx response } 
} 



The expected test body call flow sequence is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


1 




^ 








MESSAGE 


UE A sends MESSAGE to IMS A 


2 






^ 






MESSAGE 


IMS A sends MESSAGE to IMS B 


3 








^ 




MESSAGE 


IMS A sends MESSAGE to UE B 


4 








^ 




200 OK 


UE B sends 200 OK to IMS B 


5 






<r 






200 OK 


IMS B sends 200 OK to IMS A 


6 




^ 








200 OK 


IMS A sends 200 OK to UE A 
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4.4.2.1.3 



Standalone MESSAGE request procedure with implicit SIP URI 



Test description 


Identifier: 


TD IMS 0004 


Summary: 


Standalone MESSAGE request procedures with implicit SIP URI 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5097 09 


TS 124 229 [1] clause 5.4.3.2 paragraph 1 


TP IMS 5117 06 


TS 124 229 [1] clause 5.4.3.3 paragraph 49 


Use case 
reference: 


UC_05 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 100rel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UE_A, UE_B registered as per clause 4.2.3 

• UE_A, UE_B implicitly registered public identities include SIP and Tel URIs 

• UE_A, UE_B default public identity is a Tel_URI 


Test sequence: 


Step 




1 PR 


UE_A is requested to send a MESSAGE from UE_A to UE_B (prior to CFW 
step 1 ) 


2 TB 


Verify that UE_B gets the MESSAGE (prior to CFW step 4) 


Pass criteria: 


Check 




1 


TP_IMS_5097_09 in CFW step 2 (MESSAGE): 
ensure that { 
when { UE_A sends MESSAGE to UE_B 

not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
indicating a Tel URI} 
then { IMS_B receives the MESSAGE 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity and 
containing a P-Asserted-ldentity_header 
indicating a Tel_derived_SIP_URI 
and 

UE B receives the MESSAGE} 
} 






TP_IMS_51 17_06 in CFW step 5 (200 OK): 
ensure that { 
when { UEB sends 2xx_response to UEA 

not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
indicating a Tel_URI } 
then { IMS_A receives the 2xx_response 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity and 
containing a P-Asserted-ldentity_header 
indicating a Tel_derived_SIP_URI 
and 

UE A receives the 2xx response } 
} 



The expected test body call flow sequence is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


1 




^ 








MESSAGE 


UE A sends MESSAGE to IMS A 


2 






^ 






MESSAGE 


IMS A sends MESSAGE to IMS B 


3 








^ 




MESSAGE 


IMS A sends MESSAGE to UE B 


4 








^ 




200 OK 


UE B sends 200 OK to IMS B 


5 






<r 






200 OK 


IMS B sends 200 OK to IMS A 


6 




^ 








200 OK 


IMS A sends 200 OK to UE A 
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4.4.2.1.4 



Standalone MESSAGE request with DNS/ENUM lookup procedures 



Test description 


Identifier: 


TD IMS 0005 


Summary: 


Standalone MESSAGE request with DNS/ENUM lookup procedures 


Configuration: 


CF M02-SS1-MT2C 


References 


Test purpose 


Specification reference 


TP IMS 5097 10 


TS 124 229 [1] clause 5.4.3.2 paragraph 1 


Use case 
reference.: 


UC_05 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 100rel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UEA, UEB IP bearers established as per clause 4.2.1 

• UE_A, UE_B registered as per clause 4.2.3 

• UE_A, UE_B registered public identities are SIP URIs only 

• DNS_B is configured with a DNS/ENUM entry mapping UE_B's E.164 number 
to its SIP URI public identity 


Test sequence: 


Step 




1 PR 


UE_A is requested to send a MESSAGE from UE_A to UE_B (prior to CFW 
step 1 ) 


2 TB 


Verify that UE_B gets the MESSAGE (prior to CFW step 4) 


Pass criteria: 


Check 




1 


TP_IMS_5097_10 in CFW step 2 (MESSAGE): 
ensure that { 
when { UE_A sends MESSAGE to UE_B 
containing a Request_URI 
indicating a Tel_URI} 
then { IMS_A sends a DNS_Query to DNS_B 

containing the Tel_URI_E. 164_Number} 
when { IMS_A receives DNS_Response 

containing a NAPTR Resource Record 
indicating the SIP URI of UE B] 
then { IMS_A sends the MESSAGE to IMS_B 
containing a Request_URI 
indicating a SIP_URI 
and 

UE B receives the MESSAGE} 
} 



The expected test body call flow sequence is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


1 




^ 








MESSAGE 


UE A sends MESSAGE to IMS A 


2 






^ 






MESSAGE 


IMS A sends MESSAGE to IMS B 


3 








^ 




MESSAGE 


IMS A sends MESSAGE to UE B 


4 








^ 




200 OK 


UE B sends 200 OK to IMS B 


5 






^ 






200 OK 


IMS B sends 200 OK to IMS A 


6 




^ 








200 OK 


IMS A sends 200 OK to UE A 
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4.4.2.2 



Initial INVITE dialog procedures 



4.4.2.2.1 



Initial INVITE request procedure 



Test description 


Identifier: 


TD IMS 0006 


Summary: 


Initial INVITE request procedures 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5046 01 


TS 124 229 [1] clause 5.2.6.3 paragraph 4 


TP IMS 5097 01 


TS 124 229 [1] clause 5.4.3.2 paragraph 1 


TP IMS 5097 02 


TS 124 229 [1] clause 5.4.3.2 paragraph 1 


Use case 


UC 01 


reference.: 




Pre-test 


• Static configuration as per clause 4.3 


conditions: 


• UE_A, UE_B support 100rel, no SDP preconditions 




• UE A, UE B have no filter criteria defined in HSS 




• UE A, UE B IP bearers established as per clause 4.2.1 




• UE_A, UE_B registered as per clause 4.2.3 




• UE A, UE B registered public identities are SIP URIs only 


Test sequence: 


Step 




1 TB 


Initiate an IMS VoIP call on UE A, addressed to UE B's SIP URI (prior to 






CFWstepI) 


2PO 


Verify that UE B rings (prior to CFW step 7) 


3PO 


Verify that ringback is present at UE A (prior to CFW step 1 0) 


4PO 


Answer the call at UE B (prior to CFW step 1 6) 


5PO 


Verify that voice can be exchanged in both directions (prior to CFW step 22) 


6PO 


Release call at UE A (prior to CFW step 22) 


7PO 


Verify that call is released at UE B (prior to CFW step 25) 


Pass criteria: 


Check 




1 


TP_IMS_5046_01 in CFW step 3 (INVITE): 






ensure that { 






when { UE A sends INVITE to UE Bj 






then { IMS B receives the INVITE 






containing an additional Via header 






containing ( P-CSCF via port number and 






(P-CSCF-FQDN address or 






P-CSCF-IP_address)) of IMS_A and 






containing an additional topmost Ftecord-Route_header 






containing ( P-CSCF _port_number 'where it awaits subsequent 






requests from the called party' and 






(P-CSCF-FQDN address or 






P-CSCF-IP_address)) of IMS_A and 






not containing P-Preferred-ldentity_header and 






containing P-Asserted-ldentity_header 






containing an address of UE A and 






containing P-Charging- Vector_header 






containing icid_parameter 






and 






UE B receives INVITE 
} 
} 




2 


TP_IMS_5097_01 in CFW step 3 (INVITE): 
ensure that { 
when {UE A sends an initial INVITE to UE B} 
then { IMS_B receives the initial INVITE 

containing a P-Charging-Vector_header 
containing a icid_parameter 
and 

UE B receives the INVITE} 
I 



ETSI 



24 



ETSI TS 186 011-2 V1.0.0 (2008-04) 



Test description 



TP_IMS_5097_02 in CFW step 3 (INVITE): 
ensure that { 
when { UE_A sends initial INVITE to UE_B 

containing a P-Access-Network-lnfo_header } 
then { IMS_B receives the initial INVITE 

containing a topmost Record-Route_header 

indicating the originating S-CSCF_SIP_URI and 
containing a P-Charging-Vector_header 
(containing a orig-ioijparameter 

indicating IMS_A and 
not containing a access-network-charging-info_parameter) 



and 



not containing a P-Access-Network-lnfo_header 
and 
UE_B receives the INVITE} 



The expected test body call flow sequence is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


1 




^ 








INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


2 




^ 








100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


3 






^ 






INVITE 


IMS A S-CSCF forwards INVITE to IMS B I- 
CSCF 


4 






^ 






100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


5 








^ 




INVITE 


IMS B P-CSCF forwards INVITE to UE B 


6 








*- 




100 Trying 


UE_B responds with a 100 Trying provisional 
response 
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4.4.2.2.2 



1xx provisional response to initial INVITE request procedures 



Test description 


Identifier: 


TD IMS 0007 


Summary: 


1xx provisional response to initial INVITE request procedure 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5055 01 


TS 124 229 [1] clause 5.2.6.4 paragraph 15 


TP IMS 5115 01 


TS 124 229 [1] clause 5.4.3.3 paragraph 44 


TP IMS 5131 01 


TS 124 229 [1] clause 5.3.2.1 paragraph 44 


Use case 
reference.: 


UC_01 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 100rel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UE_A, UE_B registered as per clause 4.2.3 

• UE A, UE B registered public identities are SIP URIs only 


Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to UE B's SIP URI (prior to 
CFWstepI) 


2 PR 


Verify that UE B rings (prior to CFW step 7) 


3 TB 


Verify that ringback is present at UE A (prior to CFW step 10) 


4PO 


Answer the call at UE B (prior to CFW step 1 6) 


5PO 


Verify that voice can be exchanged in both directions (prior to CFW step 22) 


6PO 


Release call at UE A (prior to CFW step 22) 


7PO 


Verify that call is released at UE B (prior to CFW step 25) 


Pass criteria: 


Check 




1 


TP_IMS_5055_01 in CFW step 8 (180 Ringing): 
ensure that { 
when { UEB sends a 1xx_response to UEA } 
then { IMS_A receives 1xx_response 

containing Record-Route_header 
containing the P-CSCF_port_number of IMS_B 'where it expects 

subsequent requests' and 
not containing compjparameter and 
not containing P-Preferred-ldentity_header and 
containing P-Asserted-ldentity_header 
indicating the address 'sent in P-Called_Party-ID header 

of the initial request' 
and 

UE A receives 1xx response 
} 
} 




2 


TP_IMS_5115_01 in CFW step 8 (180 Ringing): 
ensure that { 
when { UEB sends 1xx_response to UEA } 
then { IMS_A receives the Ixxresponse 

containing a P-Charging-Vector_header 
containing a orig-ioi_parameter 

indicating IMS_A and 
containing a term-ioi_parameter 
indicating IMS_B 
and 

UE A receives the 1xx response } 
} 




3 


TP_IMS_5131_01 in CFW step 8 (180 Ringing): 
ensure that { 
when { UEB sends 1xx_response to UEA } 
then { IMS_A receives the Ixxresponse 

not containing a P-Charging-Function-Addresses_header 
and 

UE A receives the 1xx response } 
} 
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The expected test body call flow sequence is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


u 

E 
B 


7 






<r 




180 Ringing 


UE_B responds to initial INVITE with 180 Ringing to 
indicate that it has started alerting 


8 




< 






180 Ringing 


IMS B S-CSCF forwards 180 Ringing response 
to IMS A S-CSCF 


9 




<- 






180 Ringing 


IMS A P-CSCF forwards the 180 Ringing response 
to UE A 


10 




■* 






PRACK 


UE_A acknowledges the receipt of 180 response by 
sending PRACK 



4.4.2.2.3 2xx final response and ACK for initial INVITE request procedures 



Test description 


Identifier: 


TD IMS 0008 


Summary: 


2xx final response and ACK for initial INVITE request procedures 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5055 02 


TS 124 229 [1] clause 5.2.6.4 paragraph 15 


TP IMS 5115 02 


TS 124 229 [1] clause 5.4.3.3 paragraph 44 


TP IMS 5131 02 


TS 124 229 [1] clause 5.3.2.1 paragraph 44 


TP IMS 5107 03 


TS 124 229 [1] clause 5.4.3.2 paragraph 49 


Use case 
reference.: 


UC_01 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 100rel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UE_A, UE_B registered as per clause 4.2.3 

• UE A, UE B registered public identities are SIP URIs only 


Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to UE B's SIP URI (prior to 
CFWstepI) 


2 PR 


Verify that UE B rings (prior to CFW step 7) 


3 PR 


Verify that ringback is present at UE A (prior to CFW step 1 0) 


4 TB 


Answer the call at UE_B (prior to CFW step 16) 


5PO J 


Verify that voice can be exchanged in both directions (prior to CFW step 22) 


6PO 


Release call at UE A (prior to CFW step 22) 


7PO 


Verify that call is released at UE B (prior to CFW step 25) 


Pass criteria: 


Check 




1 


TP_IMS_5055_02 in CFW step 17 (200 Ok): 
ensure that { 
when { UEB sends a 2xx_response to UEA } 
then { IMS_A receives 2xx_response 

containing Record-Route_header 
containing the P-CSCF_port_number of IMS_B 'where it expects 
subsequent requests' and 

not containing compjparameter and 
not containing P-Preferred-ldentity_header and 
containing P-Asserted-ldentity_header 
indicating the address 'sent in P-Called_Party-ID header of the 
initial request' 
and 

UE B receives 2xx response 
} 
} 
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Test description 




2 


TP_IMS_51 15_02 in CFW step 17 (200 Ok): 
ensure that { 
when { UEB sends 2xx_response to UEA } 
then { IMS_A receives the 2xx_response 

containing a P-Charging-Vector_header 
containing an orig-ioijparameter 

indicating IMS_A and 
containing a term-ioi_parameter 
indicating IMS_B 
and 

UE A receives the 2xx response } 
} 




3 


TP_IMS_5131_02 in CFW step 17 (200 Ok): 
ensure that { 
when { UEB sends 2xx_response to UEA } 
then { IMS_A receives the 2xx_response 

not containing a P-Charging-Function-Addresses_header 
and 

UE A receives the 2xx response } 
} 




4 


TP_IMS_5107_03 in CFW step 20 (ACK): 
ensure that { 
when { (UE_A sends ACK to UE_B) 

containing a P-Access-Network-lnfo_header } 
then { IMS_B receives the ACK 

( containing a P-Charging-Vector_header 

not containing a access-network-charging-info_parameter 
or 

not containing a P-Charging-Vector_header ) 
and 

not containing a P-Access-Network-lnfo_header 
and 

UE B receives the ACK} 
} 



The expected test body call flow sequence is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


16 








^ 




200 OK 


UE_B responds INVITE with 200 OK to indicate that 
the call has been answered 


17 






<- 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


18 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


19 




^ 








ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 


20 






■» 






ACK 


IMS A S-CSCF forwards ACK to IMS B 
S-CSCF 


21 








^ 




ACK 


IMS B P-CSCF forwards ACK to UE B 
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4.4.2.2.4 



Initial INVITE request procedure with implicit Tel URI 



Test description 


Identifier: 


TD IMS 0009 


Summary: 


Initial INVITE request procedure with implicit Tel URI 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5097 03 


TS 124 229 [1] clause 5.4.3.2 paragraph 1 


Use case 
reference.: 


UC_01 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 100rel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UEA, UEB IP bearers established as per clause 4.2.1 

• UE_A, UE_B registered as per clause 4.2.3 

• UE_A, UE_B implicitly registered public identities include SIP and Tel URIs 

• UE A, UE B default public identity is a SIP URI 


Test sequence: 


Step 




1 TB 


Initiate an IMS VoIP call on UE A, addressed to UE B's SIP URI (prior to 
CFWstepI) 


2PO 


Verify that UE B rings (prior to CFW step 7) 


3PO 


Verify that ringback is present at UE A (prior to CFW step 1 0) 


4PO 


Answer the call at UE B (prior to CFW step 16) 


5PO 


Verify that voice can be exchanged in both directions (prior to CFW step 22) 


6PO 


Release call at UE A (prior to CFW step 22) 


7PO 


Verify that call is released at UE B (prior to CFW step 25) 


Pass criteria: 


Check 




1 


TP_IMS_5097_03 in CFW step 3 (INVITE): 
ensure that { 
when { UE_A sends initial INVITE to UE_B 

not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
not indicating a Tel_URI} 
then { IMS_B receives the initial INVITE 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity and 
containing a P-Asserted-ldentity_header 
indicating a Tel_URI 
and 

UE B receives the INVITE} 
} 



The expected test body call flow sequence is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


1 




^ 








INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


2 




^ 








100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


3 






■» 






INVITE 


IMS A S-CSCF forwards INVITE to IMS B I- 
CSCF 


4 






^ 






100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


5 








^ 




INVITE 


IMS B P-CSCF forwards INVITE to UE B 


6 








^ 




100 Trying 


UE_B responds with a 100 Trying provisional 
response 
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4.4.2.2.5 1xx provisional response to initial INVITE request procedures with implicit Tel 

URI 



Test description 


Identifier: 


TD IMS 0010 


Summary: 


1xx provisional response to initial INVITE request procedures with implicit Tel URI 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5115 03 


TS 124 229 [1] clause 5.4.3.3 paragraph 44 


Use case 
reference.: 


UC_01 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 100rel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UE_A, UE_B registered as per clause 4.2.3 

• UE_A, UE_B implicitly registered public identities include SIP and Tel URIs 

• UE A, UE B default public identity is a SIP URI 


Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to UE B's SIP URI (prior to 
CFWstepI) 


2 PR 


Verify that UE B rings (prior to CFW step 7) 


3 TB 


Verify that ringback is present at UE A (prior to CFW step 10) 


4PO 


Answer the call at UE B (prior to CFW step 1 6) 


5PO 


Verify that voice can be exchanged in both directions (prior to CFW step 22) 


6PO 


Release call at UE A (prior to CFW step 22) 


7PO 


Verify that call is released at UE B (prior to CFW step 25) 


Pass criteria: 


Check 




1 


TP_IMS_5115_03 in CFW step 8 (180 Ringing): 
ensure that { 
when { UEB sends 1xx_response to UEA 

not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
indicating a SIP_URI} 
then { IMS_A receives the Ixxresponse 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity and 
containing a P-Asserted-ldentity_header 
indicating a Tel_URI 
and 

UE A receives the 1xx response } 
} 



The expected test body call flow sequence is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


7 








^ 




180 Ringing 


UE_B responds to initial INVITE with 180 Ringing to 
indicate that it has started alerting 


8 






<r 






180 Ringing 


IMS B S-CSCF forwards 180 Ringing response 
to IMS A S-CSCF 


9 




^ 








180 Ringing 


IMS A P-CSCF forwards the 180 Ringing response 
to UE A 


10 




^ 








PRACK 


UE_A acknowledges the receipt of 180 response by 
sending PRACK 
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4.4.2.2.6 2xx final response to initial INVITE request procedures with implicit Tel URI 



Test description 


Identifier: 


TD IMS 0011 


Summary: 


2xx final response to initial INVITE request procedures with implicit Tel URI 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5115 04 


TS 124 229 [1] clause 5.4.3.3 paragraph 44 


Use case 
reference.: 


UC_01 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 100rel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UEA, UEB IP bearers established as per clause 4.2.1 

• UE_A, UE_B registered as per clause 4.2.3 

• UE_A, UE_B implicitly registered public identities include SIP and Tel URIs 

• UE A, UE B default public identity is a SIP URI 


Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to UE B's SIP URI (prior to 
CFWstepI) 


2 PR 


Verify that UE B rings (prior to CFW step 7) 


3 PR 


Verify that ringback is present at UE A (prior to CFW step 1 0) 


4 TB 


Answer the call at UE_B (prior to CFW step 16) 


5PO 


Verify that voice can be exchanged in both directions (prior to CFW step 22) 


6PO 


Release call at UE A (prior to CFW step 22) 


7PO 


Verify that call is released at UE B (prior to CFW step 25) 


Pass criteria: 


Check 




1 


TP_IMS_51 15_04 in CFW step 17 (200 Ok): 
ensure that { 
when { UEB sends 2xx_response to UEA 

not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
not indicating a Tel_URI} 
then { IMS_A receives the 2xx_response 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity and 
containing a P-Asserted-ldentity_header 
indicating a Tel_URI 
and 

UE A receives the 2xx response } 
} 



The expected test body call flow sequence is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


16 








<- 




200 OK 


UE_B responds INVITE with 200 OK to indicate that 
the call has been answered 


17 






<- 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


18 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


19 




^ 








ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 


20 






^ 






ACK 


IMS A S-CSCF forwards ACK to IMS B 
S-CSCF 


21 








■^ 




ACK 


IMS B P-CSCF forwards ACK to UE B 


22 




^ 








BYE 


UE A releases the call with BYE 
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4.4.2.2.7 



Initial INVITE request procedure with implicit SIP URI 



Test description 


Identifier: 


TD IMS 0012 


Summary: 


Initial INVITE request procedure with implicit SIP URI 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5097 04 


TS 124 229 [1] clause 5.4.3.2 paragraph 1 


Use case 
reference.: 


UC_01 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 100rel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UEA, UEB IP bearers established as per clause 4.2.1 

• UE_A, UE_B registered as per clause 4.2.3 

• UE_A, UE_B implicitly registered public identities include SIP and Tel URIs 

• UE A, UE B default public identity is a Tel URI 


Test sequence: 


Step 




1 TB 


Initiate an IMS VoIP call on UE A, addressed to UE B's SIP URI (prior to 
CFWstepI) 


2PO 


Verify that UE B rings (prior to CFW step 7) 


3PO 


Verify that ringback is present at UE A (prior to CFW step 1 0) 


4PO 


Answer the call at UE B (prior to CFW step 16) 


5PO 


Verify that voice can be exchanged in both directions (prior to CFW step 22) 


6PO 


Release call at UE A (prior to CFW step 22) 


7PO 


Verify that call is released at UE B (prior to CFW step 25) 


Pass criteria: 


Check 




1 


TP_IMS_5097_04 in CFW step 3 (INVITE): 
ensure that { 
when { UE_A sends initial INVITE to UE_B 

not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
indicating a Tel_URI } 
then { IMS_B receives the initial INVITE 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity and 
containing a P-Asserted-ldentity_header 
indicating a Tel_derived_SIP_URI 
and 

UE B receives the INVITE} 
} 



The expected test body call flow sequence is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


1 




^ 








INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


2 




^ 








100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


3 






■» 






INVITE 


IMS A S-CSCF forwards INVITE to IMS B I- 
CSCF 


4 






^ 






100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


5 








^ 




INVITE 


IMS B P-CSCF forwards INVITE to UE B 


6 








^ 




100 Trying 


UE_B responds with a 100 Trying provisional 
response 
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4.4.2.2.8 1xx provisional response to initial INVITE request procedures with implicit SIP 

URI 



Test description 


Identifier: 


TD IMS 0013 


Summary: 


1xx provisional response to initial INVITE request procedures with implicit SIP URI 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5115 05 


TS 124 229 [1] clause 5.4.3.3 paragraph 44 


Use case 
reference.: 


UC_01 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 100rel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UE_A, UE_B registered as per clause 4.2.3 

• UE_A, UE_B implicitly registered public identities include SIP and Tel URIs 

• UE A, UE B default public identity is a Tel URI 


Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to UE B's SIP URI (prior to 
CFWstepI) 


2 PR 


Verify that UE B rings (prior to CFW step 7) 


3 TB 


Verify that ringback is present at UE A (prior to CFW step 10) 


4PO 


Answer the call at UE B (prior to CFW step 1 6) 


5PO 


Verify that voice can be exchanged in both directions (prior to CFW step 22) 


6PO 


Release call at UE A (prior to CFW step 22) 


7PO 


Verify that call is released at UE B (prior to CFW step 25) 


Pass criteria: 


Check 




1 


TP_IMS_51 15_05 in CFW step 8 (180 Ringing): 
ensure that { 
when { UEB sends 1xx_response to UEA 

not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
indicating a Tel_URI } 
then { IMS_A receives the Ixxresponse 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity and 
containing a P-Asserted-ldentity_header 
indicating a Tel_derived_SIP_URI 
and 

UE A receives the 1xx response } 
} 



The expected test body call flow sequence is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


u 

E 
B 


7 






<r 




180 Ringing 


UE_B responds to initial INVITE with 180 Ringing to 
indicate that it has started alerting 


8 




< 






180 Ringing 


IMS B S-CSCF forwards 180 Ringing response 
to IMS A S-CSCF 


9 




^ 






180 Ringing 


IMS A P-CSCF forwards the 180 Ringing response 
to UE A 


10 




^ 






PRACK 


UE_A acknowledges the receipt of 180 response by 
sending PRACK 
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4.4.2.2.9 2xx final response to initial INVITE request procedures with implicit SIP URI 



Test description 


Identifier: 


TD IMS 0014 


Summary: 


2xx final response to initial INVITE request procedures with implicit SIP URI 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5115 06 


TS 124 229 [1] clause 5.4.3.3 paragraph 44 


Use case 
reference.: 


UC_01 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 100rel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UEA, UEB IP bearers established as per clause 4.2.1 

• UE_A, UE_B registered as per clause 4.2.3 

• UE_A, UE_B implicitly registered public identities include SIP and Tel URIs 

• UE A, UE B default public identity is a Tel URI 


Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to UE B's SIP URI (prior to 
CFWstepI) 


2 PR 


Verify that UE B rings (prior to CFW step 7) 


3 PR 


Verify that ringback is present at UE A (prior to CFW step 1 0) 


4 TB 


Answer the call at UE_B (prior to CFW step 16) 


5PO 


Verify that voice can be exchanged in both directions (prior to CFW step 22) 


6PO 


Release call at UE A (prior to CFW step 22) 


7PO 


Verify that call is released at UE B (prior to CFW step 25) 


Pass criteria: 


Check 




1 


TP_IMS_51 15_06 in CFW step 17 (200 Ok): 
ensure that { 
when { UEB sends 2xx_response to UEA 

not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
indicating a Tel_URI } 
then { IMS_A receives the 2xx_response 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity and 
containing a P-Asserted-ldentity_header 
indicating a Tel_derived_SIP_URI 
and 

UE A receives the 2xx response } 
} 



The expected test body call flow sequence is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


16 








<- 




200 OK 


UE_B responds INVITE with 200 OK to indicate that 
the call has been answered 


17 






<- 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


18 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


19 




^ 








ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 


20 






^ 






ACK 


IMS A S-CSCF forwards ACK to IMS B 
S-CSCF 


21 








■^ 




ACK 


IMS B P-CSCF forwards ACK to UE B 
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4.4.2.2.10 



Initial INVITE request with DNS/ENUM lookup procedures 



Test description 


Identifier: 


TD IMS 0015 


Summary: 


Initial INVITE request with DNS/ENUM lookup procedures 


Configuration: 


CF M02-SS1-MT2C 


References 


Test purpose 


Specification reference 


TP IMS 5097 05 


TS 124 229 [1] clause 5.4.3.2 paragraph 1 


Use case 
reference.: 


UC_01 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 100rel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UEA, UEB IP bearers established as per clause 4.2.1 

• UE_A, UE_B registered as per clause 4.2.3 

• UE_A, UE_B registered public identities are SIP URIs only 

• DNS_B is configured with a DNS/ENUM entry mapping UE_B's E.164 number 
to its SIP URI public identity 


Test sequence: 


Step 




1 TB 


Initiate an IMS VoIP call on UE A, addressed to UE B's SIP URI (prior to 
CFWstepI) 


2 TB 


Verify that UE_B rings (prior to CFW step 7) 


3PO 


Verify that ringback is present at UE A (prior to CFW step 1 0) 


4PO 


Answer the call at UE B (prior to CFW step 1 6) 


5PO 


Verify that voice can be exchanged in both directions (prior to CFW step 22) 


6PO 


Release call at UE A (prior to CFW step 22) 


7PO 


Verify that call is released at UE B (prior to CFW step 25) 


Pass criteria: 


Check 




1 


TP_IMS_5097_05 in CFW step 3 (INVITE): 
ensure that { 
when { UE_A sends initial INVITE to UE_B 
containing a Request_URI 
indicating a Tel_URI} 
then { IMS_A sends a DNS_Query to DNS_B 

containing the Tel_URI_E. 164_Number} 
when { IMS_A receives DNS_Response 

containing a NAPTR Resource Record 
indicating the SIP URI of UE B} 
then { IMS_A sends the initial INVITE to IMS_B 
containing a Request_URI 
indicating a SIP_URI 
and 

UE B receives the INVITE} 
} 



The expected test body call flow sequence is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


1 




^ 








INVITE 


UE_A sends INVITE with the first SDP offer indicating 
all desired medias and codecs that UE A supports 


2 




^ 








100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


3 






■* 






INVITE 


IMS A S-CSCF forwards INVITE to IMS B l-CSCF 


4 






^ 






100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


5 








^ 




INVITE 


IMS B P-CSCF forwards INVITE to UE B 


6 








^ 




100 Trying 


UE_B responds with a 100 Trying provisional 
response 


7 








^ 




180 Ringing 


UE_B responds to initial INVITE with 180 Ringing to 
indicate that it has started alerting 
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4.4.2.3 



Special case of initial INVITE dialog procedures 



4.4.2.3.1 



P-CSCF initiated session release, session establishment cancelled 



Test description 


Identifier: 


TD IMS 0016 


Summary: 


P-CSCF-initiated session release, session establishment cancelled, resources no 
longer available 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5072 01 


TS 124 22911] clause 5.2.8.1.1 paragraph 1 


Use case 
reference.: 


UC_04 (CFW for Cancelled) 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 100rel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UE_A, UE_B registered as per clause 4.2.3 

• UE_A, UE_B registered public identities are SIP URIs only 

• P-CSCF can receive notifications of UE A network access failures 


Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to UE B's SIP URI (prior to 
CFW step 1) 


2 PR 


Verify that UE B rings (prior to CFW step 7) 


3 PR 


Verify that ringback is present at UE A (prior to CFW step 1 0) 


4 TB 


Remove cable, antenna or battery from UE A (prior to CFW step 16) 


5 TB 


Verify that call is ended at UE_B (prior to CFW step 20) 


Pass criteria: 


Check 




1 


TP_IMS_5072_01 in CFW step 17 (CANCEL): 
ensure that { 
when { IMS A receives 'an indication that UE A is no longer available' } 
then { IMS A sends a CANCEL to IMS B and 
UE B receives the CANCEL 
} 
} 



The expected test body call flow is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


16 












LOSS 


PDF or SPDF sends a message that resources are 
missing for UE A 


17 






■* 






CANCEL 


IMS A sends CANCEL to IMS B 


18 






^ 






200 OK 


IMS B S-CSCF responds with a 200 OK 


19 








^ 




CANCEL 


IMS B sends CANCEL to UE B 


20 








^ 




200 OK 


UE_B responds with 200 OK 
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4.4.2.3.2 



P-CSCF initiated session release, session released from originating network 



Test description 


Identifier: 


TD IMS 0017 


Summary: 


P-CSCF-initiated session release, session released from originating network 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5073 01 


TS 124 229 [1] clause 5.2.8.1.2 paragraph 1 


Use case 
reference.: 


UC_04 (CFW for originating network) 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 100rel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UEA, UEB IP bearers established as per clause 4.2.1 

• UE_A, UE_B registered as per clause 4.2.3 

• UE_A, UE_B registered public identities are SIP URIs only 

• P-CSCF can receive notifications of UE A network access failures 


Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to UE B's SIP URI (prior to 
CFW step 1) 


2 PR 


Verify that UE B rings (prior to CFW step 7) 


3 PR 


Verify that ringback is present at UE A (prior to CFW step 1 0) 


4 PR 


Answer the call at UE B (prior to CFW step 16) 


5 PR 


Verify that voice can be exchanged in both directions (prior to CFW step 22) 


6 TB 


Remove cable, antenna or battery from UE_A (prior to CFW step 22) 


7 TB 


Verify that call is released at UE_B (prior to CFW step 25) 


Pass criteria: 


Check 




1 


TP_IMS_5073_01 in CFW step 23 (BYE): 
ensure that { 
when {UE A is no longer available } 
then { IMS_B receives BYE from IMS_A 
containing Request_URI 

indicating the Contact_header_value of UEB and 
containing To_header 

indicating the initial 200_OK_To_header_value from UEB 
containing From_header 

indicating the initial INVITE_From_header_value from UEA 
and 
containing Call-ID_header 

indicating the initial INVITE_Call_ld_header_value from UEA 
and 
containing CSeq_header 

indicating an incremented Sequence_Number and 
containing Route_header 

indicating 'dialog specific routing information for UEB' and 
'further headers based on local policy or call release reason' 
and 

UE B receives BYE 
} 
} 



The expected test body call flow is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


22 












LOSS 


PDF or SPDF sends a message that resources are 
missing for UE A 


23 






■* 






BYE 


IMS A P-CSCF sends BYE to IMS B 
S-CSCF 


24 








^ 




BYE 


IMS B P-CSCF forwards BYE to UE B 


25 








^ 




200 OK 


UE B sends 200 OK for BYE 
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4.4.2.3.3 



P-CSCF initiated session release, session released from terminating network 



Test description 


Identifier: 


TD IMS 0018 


Summary: 


P-CSCF-initiated session release, session released from terminating network 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5074 01 


TS 124 229 [1] clause 5.2.8.1.2 paragraph 10 


Use case 
reference.: 


UC_04 (CFW for terminating network) 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 100rel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UEA, UEB IP bearers established as per clause 4.2.1 

• UE_A, UE_B registered as per clause 4.2.3 

• UE_A, UE_B registered public identities are SIP URIs only 

• P-CSCF can receive notifications of UE B network access failures 


Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to UE B's SIP URI (prior to 
CFW step 1) 


2 PR 


Verify that UE B rings (prior to CFW step 7) 


3 PR 


Verify that ringback is present at UE A (prior to CFW step 1 0) 


4 PR 


Answer the call at UE B (prior to CFW step 16) 


5 PR 


Verify that voice can be exchanged in both directions (prior to CFW step 22) 


6 TB 


Remove cable, antenna or battery from UEB (prior to CFW step 22) 


7 TB 


Verify that call is released at UE_A (prior to CFW step 25) 


Pass criteria: 


Check 




1 


TP_IMS_5074_01 in CFW step 23 (BYE): 
ensure that { 
when { UE B is no longer available } 
then { IMS_A receives BYE from IMS_B 
containing Request_URI 

indicating the Contact_header_value of UEA and 
containing To_header 

indicating the initial INVITE_To_header_value from UEA 
containing From_header 

indicating the initial 200_OK_From_header_value from UEB 
and 
containing Call-ID_header 

indicating the initial INVITE_Call_ld_header_value from UEA 
and 
containing CSeq_header 

indicating an incremented Sequence_Number and 
containing Route_header 

indicating 'dialog specific routing information for UEA' and 
'further headers based on local policy or call release reason' 
and 

UE A receives BYE 
} 
} 



The expected test body call flow sequence is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


22 












LOSS 


PDF or SPDF(in IMS_B) sends a message that 
resources are missing for UE B 


23 






<r 






BYE 


IMS A P-CSCF sends BYE to IMS B 
S-CSCF 


24 




^ 








BYE 


IMS B P-CSCF forwards BYE to UE B 


25 




^ 








200 OK 


UE B sends 200 OK for BYE 
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4.4.2.3.4 



Initial request to non-existent user procedures 



Test description 


Identifier: 


TD IMS 0019 


Summary: 


Initial INVITE request to non-existent user procedures 


Configuration: 


CF M02-SS1 


References 


Test purpose 


Specification reference 


TP IMS 5132 01 


TS 124 229 [1] clause 5.3.2.1 paragraph 32 


Use case 
reference.: 


UC_01 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A support 100rel, no SDP preconditions 

• UE_A have no filter criteria defined in HSS 

• UE_A IP bearers established as per clause 4.2.1 

• UE_A registered as per clause 4.2.3 

• UE A registered public identities are SIP URIs only 


Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE_A, addressed to 
sip:non existent user@ims b.net (prior to CFW step 1) 


2 TB 


Verify that an error is received and call is aborted at UE A (after CFW 
step 6) 


Pass criteria: 


Check 




1 


TP_IMS_5132_01 in CFW step 5 (404 or 604 Response): 
ensure that { 
when { UE_A sends INVITE 

containing a Ftequest_URI 
indicating a non existing user in IMS B) 
then { IMS_B receives the INVITE 
and 

IMS_B sends (a 404_response or a 604_response) 
and 

UE A receives the response } 
} 



The expected test body call flow sequence is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


1 




^ 








INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


2 




^ 








100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


3 






^ 






INVITE 


IMS A S-CSCF forwards INVITE to IMS B l-CSCF 


4 






^ 






100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


5 






«- 






404 Not Found or 

604 Does not exist anywhere 


IMS_B l-CSCF generates error message 
indicating non-existent user 


6 




^ 








404 Not Found or 

604 Does not exist anywhere 


IMS_A P-CSCF forwards error response to UEA 
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4.4.2.3.5 



Initial request to non-registered user with no filter criterion 



Test description 


Identifier: 


TD IMS 0020 


Summary: 


Initial request to non-registered user with no filter criterion 


Configuration: 


CF M02-SS1-MT2b 


References 


Test purpose 


Specification reference 


TP IMS 5133 01 


TS 124 229 [1] clause 5.3.2.1 paragraph 33 


Use case 
reference.: 


UC_01 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 100rel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UEA, UEB IP bearers established as per clause 4.2.1 

• UE_A registered as per clause 4.2.3 

• UEB not registered 

• UEA registered public identities are SIP URIs only 


Test sequence: 


Step 




1 TB 


Initiate an IMS VoIP call on UE A, addressed to UE B's SIP URI (prior to 
CFWstepI) 


2 TB 


Verify that error is received and call is aborted at UE A (after CFW step 
6) 


Pass criteria: 


Check 




1 


TP_IMS_5133_01 in CFW step 5 (480 Response): 
ensure that { 
when { UE A sends INVITE to UE Bj 
then { IMS_B receives the INVITE and 

sends a 480_response to IMS_A 
and 
UE A receives the 480 response } 
} 



The expected test body call flow sequence is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


1 




^ 








INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


2 




^ 








100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


3 






^ 






INVITE 


IMS A S-CSCF forwards INVITE to IMS B l-CSCF 


4 






^ 






100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


5 






«- 






480 Temporarily unavailable 


IMS_B l-CSCF generates error message 
indicating unavailable user 


6 




^ 








480 Temporarily unavailable 


IMS_A P-CSCF forwards error response to UE_A 
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4.4.2.3.6 



Initial request to non-registered user with terminating unregistered filter criterion 



Test description 


Identifier: 


TD IMS 0021 


Summary: 


Initial request to non-registered user with terminating unregistered filter criterion 


Configuration: 


CF M02-SS1-MT2-AST4b 


References 


Test purpose 


Specification reference 


TP IMS 5133 01 


TS 124 229 [1] clause 5.3.2.1 paragraph 33 


Use case 
reference.: 


UC_01 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 100rel, no SDP preconditions 

• UE_A has no filter criteria defined in HSS 

• IMS B has terminating unregistered criterion for UE B on INVITE indicating 
SESSION_TERMINATED option 

• Target AS in IMS_B is unreachable 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UE_A registered as per clause 4.2.3 

• UEB not registered 

• UE A registered public identities are SIP URIs only 


Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to UE B's SIP URI (prior to 
CFW step 1 ) 


2 TB 


Verify that error is received and call is aborted at UE A (prior to CFW 
step 6) 


Pass criteria: 


Check 




1 


TP_IMS_5109_01 in CFW step 5 (Error Response): 
ensure that { 
when { UE A sends INVITE to UE_B} 
then { IMS_B receives the INVITE and 

sends (a 408_response or a 5xx_response) to IMS_A 
and 
UE A receives the response } 
} 
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The expected test body call flow sequence is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


1 




^ 








INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


2 




^ 








100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


3 






^ 






INVITE 


IMS A S-CSCF forwards INVITE to IMS B l-CSCF 


4 






^ 






100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


5 






^ 






408 Request Timeout or 
5xx Response 


IMS_B l-CSCF forwards S-CSCF error message 
indicating unreachable AS 


6 




^ 








408 Request Timeout or 
5xx Response 


IMS_A P-CSCF forwards error response to UEA 



4.4.2.3.7 



S-CSCF initiated session release from originating network 



Test description 


Identifier: 


TD IMS 0022 


Summary: 


S-CSCF-initiated release of established session from originating network 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5139 01 


TS 124 229 [1] clause 5.4.5.1.2 paragraph 1 


Use case 
reference.: 


UC_03 (CFW for originating network) 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 100rel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UE_A registered as per clause 4.2.3 

• UEA registered public identities are SIP URIs only 


Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to UE B's SIP URI (prior to 
CFW step 1) 


2 PR 


Verify that UE B rings (prior to CFW step 7) 


3 PR 


Verify that ringback is present at UE A (prior to CFW step 1 0) 


4 PR 


Answer the call at UE B (prior to CFW step 16) 


5 PR 


Verify that voice can be exchanged in both directions (prior to CFW step 22) 


6 TB 


Set UE A registration status to de-registered in IMS A HSS (prior to 
CFW step 22) 


7 TB 


Verify that call is ended at UE_B (prior to CFW step 24) 


8PO 


Verify that call is ended at UE A (prior to CFW step 27) 


9PO 


Verify that UE_A is deregistered 
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Test description 


Pass criteria: 


Check 




1 


TP_IMS_5139_01 in CFW step 22 (BYE): 
ensure that { 
when { IMS A receives 'an indication that UE A is to be de-registered' } 
then { IMS_A sends a BYE to IMS_B 
containing Request_URI 

indicating the Contact_header_value of UEB and 
containing To_header 

indicating the initial 200_OK_To_value from UEB 
containing From_header 

indicating the initial INVITE_From_value from UEA and 
containing Call-ID_header 

indicating the initial INVITE_Call_ld_value from UEA and 
containing CSeq_header 

indicating an incremented Sequence_Number and 
containing Route_header 

indicating 'dialog specific routing information for UEB' and 
'further headers based on local policy or call release reason' 
and 

UE B receives BYE 
} 
} 



The expected TB call flow is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


I 

M 
S 
B 


U 

E 
B 


22 






^ 






BYE 


IMS_A S-CSCF releases the call towards the 
called user with BYE 


23 








^ 




BYE 


IMS B P-CSCF forwards BYE to UE B 


24 








^ 




200 OK 


UE B sends 200 OK for BYE 


25 






^ 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


26 




^ 








BYE 


IMS_A S-CSCF releases the call towards the calling 
user with BYE 


27 




^ 








200 OK 


UE_A sends 200 OK for BYE 
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4.4.2.3.8 



S-CSCF initiated session release from terminating network 



Test description 


Identifier: 


TD IMS 0023 


Summary: 


S-CSCF-initiated release of established session from terminating network 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5139 02 


TS 124 229 [1] clause 5.4.5.1.2 paragraph 1 


Use case 
reference.: 


UC_03 (CFW for terminating network) 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 100rel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UEA, UEB IP bearers established as per clause 4.2.1 

• UE_A registered as per clause 4.2.3 

• UEA registered public identities are SIP URIs only 


Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to UE B's SIP URI (prior to 
CFW step 1) 


2 PR 


Verify that UE B rings (prior to CFW step 7) 


3 PR 


Verify that ringback is present at UE A (prior to CFW step 9) 


4 PR 


Answer the call at UE B (prior to CFW step 1 6) 


5 PR 


Verify that voice can be exchanged in both directions (prior to CFW step 21 ) 


6 TB 


Set UE A registration status to de-registered in IMS A HSS (prior to 
CFW step 22) 


7 TB 


Verify that call is ended at UEA (prior to CFW step 24) 


8PO J 


Verify that call is ended at UE B (prior to CFW step 27) 


9PO 


Verify that UE A is deregistered 


Pass criteria: 


Check 




1 


TP_IMS_5139_02 in CFW step 22 (BYE): 
ensure that { 
when { IMS B receives 'an indication that UE B is no longer available'} 
then { IMS_B sends a BYE to IMS_A 
containing Request_URI 

indicating the Contact_header_value of UEA and 
containing To_header 

indicating the initial INVITE_To_value from UEA 
containing From_header 

indicating the initial 200_OK_From_value from UEB and 
containing Call-ID_header 

indicating the initial INVITE_Call_ld_value from UEA and 
containing CSeq_header 

indicating an incremented Sequence_Number and 
containing Route_header 

indicating 'dialog specific routing information for UEA' and 
'further headers based on local policy or call release reason' 
and 

UE A receives BYE 
} 
} 
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The expected TB call flow is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


I 

M 
S 
B 


U 

E 
B 


22 






<- 






BYE 


IMSB S-CSCF releases the call towards the 
calling user with BYE 


23 




^ 








BYE 


IMS A P-CSCF forwards BYE to UE B 


24 




^ 








200 OK 


UE A sends 200 OK for BYE 


25 






■^ 






200 OK 


IMS A S-CSCF forwards 200 OK response to 
IMS B S-CSCF 


26 








^ 




BYE 


IMS_B S-CSCF releases the call towards the called 
user with BYE 


27 








^ 




200 OK 


UE B sends 200 OK for BYE 



4.4.3 Subsequent requests within dialog procedures 



4.4.3.1 



Subsequent UPDATE target refresh request procedures 



Test description 


Identifier: 


TD IMS 0024 


Summary: 


Subsequent UPDATE target refresh requests and 200 OK response procedures 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5048 02 


TS 124 229 [1] clause 5.2.6.3 paragraph 26 


TP IMS 5058 02 


TS 124 229 [1] clause 5.2.6.4 paragraph 67 


TP IMS 5106 02 


TS 124 229 [1] clause 5.4.3.2 paragraph 42 


Use case 
reference.: 


UC_02 (CFW for UPDATE) 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UEA, UEB support 100rel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UE_A, UE_B registered as per clause 4.2.3 

• UE_A, UE_B registered public identities are SIP URIs only 

• UE A, UE B support UPDATE method for call hold/resume 


Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to UE B's SIP URI (prior to 
CFW step 1) 


2 PR 


Verify that UE B rings (prior to CFW step 7) 


3 PR 


Verify that ringback is present at UE A (prior to CFW step 1 0) 


4 PR 


Answer the call at UE B (prior to CFW step 1 6) 


5 PR 


Verify that voice can be exchanged in both directions (prior to CFW step 22) 


6 TB 


Place call on hold at UE_A (prior to CFW step 22) 


7 TB 


Verify that voice can no longer be exchanged in both directions (prior to 
CFW step 25) 


8 TB 


Resume call at UE_A (prior to CFW step 28) 


9 TB 


Verify that voice can be exchanged in both directions (prior to CFW step 
31) 


10 PO 


Release call at UE A (prior to CFW step 34) 


11 PO 


Verify that call is released at UE_B (prior to CFW step 37) 
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Test description 


Pass criteria: 


Check 




1 


TP_IMS_5048_02 in CFW step 23 and 29 (UPDATE): 
ensure that { 
when { UE A sends UPDATE to UE B } 
then { IMS_B receives the UPDATE 

containing an additional Via_header 
containing ( P-CSCF_port_number 'where it awaits the responses 
to arrive' and 

(P-CSCF-FQDN address or 
P-CSCF-IP_address)) of IMS_A and 
containing an additional topmost Record-Route_header 
containing ( P-CSCF_port_number 'where it awaits subsequent 
requests from the called party' and 

(P-CSCF-FQDN address or 
P-CSCF-IP_address)) of IMS_A 
and 

UE B receives UPDATE 
} 
} 






TP_IMS_5058_02 in CFW step 26 and 32 (200 Ok): 
ensure that { 
when { UEB sends a 2xx_response to UEA } 
then { IMS_A receives 2xx_response 

containing Record-Route_header 
containing the same P-CSCF_port_number of IMS_B 'as in the 
response to the previous initial request' and 
not containing a compjparameter 
and 

UE A receives 2xx response 
} 
} 






TP_IMS_5106_02 in CFW step 23 and 29 (UPDATE): 
ensure that { 
when { UE_A sends subsequent UPDATE to UE_B } 
then { IMS_B receives the subsequent UPDATE 

containing a topmost Record-Route header 

containing the S-CSCF_SIP_URI of IMS_A and 
containing a P-Charging-Vector_header 
not containing a access-network-charging-info_parameter 
and 

not containing a P-Access-Network-lnfo_header 
and 

UE B receives the UPDATE} 
} 
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The expected test body (TB) call flow sequence is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


22 




^ 








UPDATE 


UEA sends UPDATE message indicating media 
stream inactive (Call Hold) 


23 






■* 






UPDATE 


IMS A S-CSCF forwards UPDATE to IMS B 
S-CSCF 


24 








^ 




UPDATE 


IMS B P-CSCF forwards UPDATE to UE B 


25 








^ 




200 OK 


UE_B responds to UPDATE with 200 OK indicating 
media stream inactive 


26 






<- 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


27 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


28 




^ 








UPDATE 


UEA sends UPDATE message indicating media 
stream active (Call Resume) 


29 






■* 






UPDATE 


IMS A S-CSCF forwards UPDATE to IMS B 
S-CSCF 


30 








^ 




UPDATE 


IMS B P-CSCF forwards UPDATE to UE B 


31 








^ 




200 OK 


UE_B responds to UPDATE with 200 OK indicating 
media stream active 


32 






<- 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


33 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 
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4.4.3.2 



Subsequent PRACK request procedures 



Test description 


Identifier: 


TD IMS 0025 


Summary: 


Subsequent PRACK requests and 200 OK response procedures 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5107 01 


TS 124 229 [1] clause 5.4.3.2 paragraph 49 


Use case 
reference.: 


UC_01 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 100rel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UE_A, UE_B registered as per clause 4.2.3 

• UE A, UE B registered public identities are SIP URIs only 


Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to UE B's SIP URI (prior to 
CFWstepI) 


2 PR 


Verify that UE B rings (prior to CFW step 7) 


3 PR 


Verify that ringback is present at UE A (prior to CFW step 9) 


4 TB 


Answer the call at UE_B (prior to CFW step 16) 


5PO 


Verify that voice can be exchanged in both directions (prior to CFW step 22) 


6PO 


Release call at UE A (prior to CFW step 22) 


7PO 


Verify that call is released at UE B (prior to CFW step 25) 


Pass criteria: 


Check 




1 


TP_IMS_5107_01 in CFW step 1 1 (PRACK): 
ensure that { 
when { (UE_A sends PRACK to UE_B) 

containing a P-Access-Network-lnfo header} 
then { IMS_B receives the PRACK 

( containing a P-Charging-Vector_header 

not containing a access-network-charging-info_parameter 
or 

not containing a P-Charging-Vector_header ) 
and 

not containing a P-Access-Network-lnfo_header 
and 

UE B receives the PRACK} 
} 


2 


TP_IMS_5121_02 in CFW step 14 (200 OK): 
ensure that { 
when { UEB sends 2xx_response to UEA } 
then { IMS_A receives the 2xx_response 

containing a P-Charging-Vector_header 
not containing a access-network-charging-info_parameter 
and 

not containing a P-Access-Network-lnfo_header 
and 

UE A receives the 2xx response } 
} 
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The expected test body (TB) call flow sequence is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


10 




^ 








PRACK 


UE_A acknowledges the receipt of 180 response by 
sending PRACK 


11 






^ 






PRACK 


IMS A S-CSCF forwards PRACK to IMS B 
S-CSCF 


12 








^ 




PRACK 


IMS B P-CSCF forwards PRACK to UE B 


13 








^ 




200 OK 


UE B responds PRACK with 200 OK 


14 






<r 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


15 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 



4.4.3.3 



Subsequent BYE request procedures 



Test description 


Identifier: 


TD IMS 0026 


Summary: 


Subsequent BYE requests and 200 OK response procedures 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5107 01 


TS 124 229 [1] clause 5.4.3.2 paragraph 49 


TP IMS 5121 02 


TS 124 229 1 clause 5.4.3.3 paragraph 60 


Use case 
reference.: 


UC_01 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 100rel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UEA, UEB IP bearers established as per clause 4.2.1 

• UE_A, UE_B registered as per clause 4.2.3 

• UE A, UE B registered public identities are SIP URIs only 


Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to UE B's SIP URI (prior to 
CFWstepI) 


2 PR 


Verify that UE B rings (prior to CFW step 7) 


3 PR 


Verify that ringback is present at UE A (prior to CFW step 1 0) 


4 PR 


Answer the call at UE B (prior to CFW step 1 6) 


5 PR 


Verify that voice can be exchanged in both directions (prior to CFW step 22) 


6 TB 


Release call at UE_A (prior to CFW step 22) 


7 TB 


Verify that call is released at UE_B (prior to CFW step 25) 


Pass criteria: 


Check 




1 


TP_IMS_5107_02 in CFW step 23 (BYE): 
ensure that { 
when { (UE_A sends BYE to UE_B) 

containing a P-Access-Network-lnfo_header } 
then { IMS_B receives the BYE 

( containing a P-Charging-Vector_header 

not containing a access-network-charging-info_parameter 
or 

not containing a P-Charging-Vector_header ) 
and 

not containing a P-Access-Network-lnfo_header 
and 

UE B receives the BYE} 
} 
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Test description 



TP_IMS_5121_02 in CFW step 26 (200 OK): 
ensure that { 
when { UEB sends 2xx_response to UEA } 
then { IMS_A receives the 2xx_response 

containing a P-Charging-Vector_header 
not containing a access-network-charging-info_parameter 
and 

not containing a P-Access-Network-lnfo_header 
and 

UEA receives the 2xx_response } 
1 



The expected test body (TB) call flow sequence is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


22 




^ 








BYE 


UE A releases the call with BYE 


23 






^ 






BYE 


IMS A S-CSCF forwards BYE to IMS B 
S-CSCF 


24 








^ 




BYE 


IMS B P-CSCF forwards BYE to UE B 


25 








^ 




200 OK 


UE B sends 200 OK for BYE 


26 






<- 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


27 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 



4.4.3.4 



Subsequent INVITE target refresh request procedures 



Test description 


Identifier: 


TD IMS 0027 


Summary: 


Subsequent INVITE target refresh requests and 200 OK response procedures 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5048 01 


TS 124 229 [1] clause 5.2.6.3 paragraph 26 


TP IMS 5058 02 


TS 124 229 [1] clause 5.2.6.4 paragraph 67 


TP IMS 5106 01 


TS 124 229 [1] clause 5.4.3.2 paragraph 42 


Use case 
reference.: 


UC_02 (CFW for relNVITE) 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A, UE_B support 100rel, no SDP preconditions 

• UE_A, UE_B have no filter criteria defined in HSS 

• UE_A, UE_B IP bearers established as per clause 4.2.1 

• UE_A, UE_B registered as per clause 4.2.3 

• UE_A, UE_B registered public identities are SIP URIs only 

• UE A, UE B support relNVITE method for call hold/resume 


Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to UE B's SIP URI (prior to 
CFW step 1) 


2 PR 


Verify that UE B rings (prior to CFW step 7) 


3 PR 


Verify that ringback is present at UE A (prior to CFW step 1 0) 


4 PR 


Answer the call at UE B (prior to CFW step 1 6) 


5PR J 


Verify that voice can be exchanged in both directions (prior to CFW step 22) 


6 TB 


Place call on hold at UE_A (prior to CFW step 22) 


7 TB 


Verify that voice can no longer be exchanged in both directions (prior to 
CFW step 28) 


8 TB 


Resume call at UE_A (prior to CFW step 34) 


9 TB 


Verify that voice can be exchanged in both directions (prior to CFW step 
40) 


10 PO 


Release call at UE_A (prior to CFW step 46) 
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Test description 




11 PO 


Verify that call is released at UE B (prior to CFW step 49) 


Pass criteria: 


Check 




1 


TP_IMS_5048_01 in CFW step 24 and 36 (INVITE): 
ensure that { 
when { UEA sends a subsequent INVITE to UE_B } 
then { IMS_B receives the subsequent INVITE 
containing an additional Via_header 
containing ( P-CSCF_port_number 'where it awaits the responses 
to arrive' and 

(P-CSCF-FQDN address or 
P-CSCF-IP_address)) of IMS_A and 
containing an additional topmost Ftecord-Route_header 
containing ( P-CSCF_port_number 'where it awaits subsequent 
requests from the called party' and 

(P-CSCF-FQDN address or 
P-CSCF-IP_address)) of IMS_A 
and 

UE B receives INVITE 
} 
} 






TP_IMS_5058_02 in CFW step 29 and 41 (200 Ok): 
ensure that { 
when { UEB sends a 2xx_response to UEA } 
then { IMS_A receives 2xx_response 

containing Record-Route_header 
containing the same P-CSCF_port_number of IMS_B 'as in the 
response to the previous initial request' and 
not containing a compjparameter 
and 

UE A receives 2xx response 
} 
} 






TP_IMS_5106_01 in CFW step 24 and 36 (INVITE): 
ensure that { 
when { UEA sends subsequent INVITE to UEB } 
then { IMS_B receives the subsequent INVITE 

containing a topmost Record-Route header 

containing the S-CSCF_SIP_URI of IMS_A and 
containing a P-Charging-Vector_header 
not containing a access-network-charging-info_parameter 
and 

not containing a P-Access-Network-lnfo_header 
and 

UE B receives the INVITE} 
} 
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The expected test body (TB) call flow sequence is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


u 

E 
B 


22 




^ 








INVITE 


UEA sends relNVITE message indicating media 
stream inactive (Call Hold) 


23 




<r 








100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


24 






^ 






INVITE 


IMS A S-CSCF forwards INVITE to IMS B 
S-CSCF 


25 






^ 






100 Trying 


IMS_B S-CSCF responds with a 100 Trying 
provisional response 


26 








^ 




INVITE 


IMS_B P-CSCF forwards INVITE to UE_B 


27 








<r 




100 Trying 


UE_B responds with a 100 Trying provisional 
response 


28 








^ 




200 OK 


UE_B responds to UPDATE with 200 OK indicating 
media stream inactive 


29 






<- 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


30 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


31 




^ 








ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 


32 






^ 






ACK 


IMS A S-CSCF forwards ACK to IMS B 
S-CSCF 


33 








^ 




ACK 


IMS B P-CSCF forwards ACK to UE B 


34 




^ 








INVITE 


UEA sends relNVITE message indicating media 
stream active (Call Resume) 


35 




^ 








100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


36 






^ 






INVITE 


IMS A S-CSCF forwards INVITE to IMS B 
S-CSCF 


37 






^ 






100 Trying 


IMS_B S-CSCF responds with a 100 Trying 
provisional response 


38 








^ 




INVITE 


IMS B P-CSCF forwards INVITE to UE B 


39 








^ 




100 Trying 


UE_B responds with a 100 Trying provisional 
response 


40 








^ 




200 OK 


UE_B responds to UPDATE with 200 OK indicating 
media stream active 


41 






^ 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


42 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


43 




^ 








ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 


44 






^ 






ACK 


IMS A S-CSCF forwards ACK to IMS B 
S-CSCF 


45 








^ 




ACK 


IMS B P-CSCF forwards ACK to UE B 
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4.4.3.5 



Subsequent CANCEL request procedures 



Test description 


Identifier: 


TD IMS 0028 


Summary: 


Subsequent CANCEL request procedures 


Configuration: 


CF M02-SS1-MT2 


References 


Test purpose 


Specification reference 


TP IMS 5107 04 


TS 124 229 [1] clause 5.4.3.2 paragraph 49 


TP IMS 5121 02 


TS 124 229 [1] clause 5.4.3.3 paragraph 60 


Use case 
reference.: 


UC_01 


Pre-test 
conditions: 


• Static configuration as per clause 4.3 

• UE_A support 100rel, no SDP preconditions 

• UE_A have no filter criteria defined in HSS 

• UE_A IP bearers established as per clause 4.2.1 

• UE_A registered as per clause 4.2.3 

• UE A registered public identities are SIP URIs only 


Test sequence: 


Step 




1 PR 


Initiate an IMS VoIP call on UE A, addressed to UE B's SIP URI (prior to 
CFWstepI) 


2PR J 


Verify that UE B rings (prior to CFW step 7) 


3 PR 


Verify that ringback is present at UE A (prior to CFW step 1 0) 


4 TB 


End call at UE_A (prior to CFW step 16) 


5PO 


Verify that call is ended at UE B (prior to CFW step 21) 


Pass criteria: 


Check 




1 


TP_IMS_5107_04 in CFW step 18 (CANCEL): 
ensure that { 
when { UE A sends CANCEL to UE B } 
then { IMS_B receives the CANCEL 

(containing a P-Charging-Vector_header 

not containing a access-network-charging-info_parameter or 
not containing a P-Charging-Vector_header) and 
not containing a P-Access-Network-lnfo_header 
and 

UE B receives the CANCEL } 
} 


2 


TP_IMS_5121_02 in CFW step 18 (200 OK): 
ensure that { 
when { UEB sends 2xx_response to UEA } 
then { IMS_A receives the 2xx_response 

(containing a P-Charging-Vector_header 
not containing a access-network-charging-info_parameter or 
not containing a P-Charging-Vector_header) and 
not containing a P-Access-Network-lnfo_header 
and 

UE A receives the 2xx response } 
} 
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The expected test body call flow sequence is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


16 




^ 








CANCEL 


UE A sends CANCEL to abort call 


17 




^ 








200 OK 


IMS A P-CSCF responds with a 200 OK response 


18 






^ 






CANCEL 


IMS A S-CSCF sends CANCEL to IMS B S- 
CSCF 


19 






«- 






200 OK 


IMS_B S-CSCF responds with a 200 OK 
response 


20 








^ 




CANCEL 


IMS B P-CSCF sends CANCEL to UE B 


21 








^ 




200 OK 


UE B responds with a 200 OK response 


22 








^ 




487 Request Terminated 


UE_B confirms cancellation of the INVITE request 
with a 487 Request Terminated error response 


23 








^ 




ACK 


IMS B P-CSCF responds with an ACK to UE B 


24 






^ 






487 Request Terminated 


IMS_B S-CSCF sends a 487 Request Terminated 
error response to IMS A S-CSCF 


25 






^ 






ACK 


IMS A S-CSCF responds with an ACK 


26 




^ 








487 Request Terminated 


IMS_B P-CSCF sends a 487 Request Terminated 
error response to UE A 


27 




^ 








ACK 


UE_A responds with an ACK 



4.5 



Use cases 



All test descriptions are based on an underlying use case, i.e. user interactions with an external IMS entity, which serves 
as the basis for stimulating the generation of SIP messages at the IMS NNI. Test procedures include the execution of the 
use case, validation of the call flow and validation of generic headers. Test requirements validate specific messages and 
headers observed over NNI. These are related to test purposes and underlying specification requirements. Use case 
descriptions, associated test sequences and call flows referenced by TDs are presented below. Call flow steps 
corresponding to specific test sequence steps are displayed with shading. 

4.5.1 UC_01 : User-initiated VoIP call setup and release 



4.5.1.1 



Description 



UE_A places an IMS VoIP call to UE_B. Once the media path is established, the originating user releases the call. We 
assume support for reliable provisional responses (lOOrel) and no SDP preconditions. The call flow path and node 
configuration for this use case corresponds to CF_M02-SS1-MT2. 

The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering): 



1 


Initiate an IMS VoIP call on UE A, addressed to UE B's SIP URI (prior to CFW step 1) 


2 


Verify that UE B rings (prior to CFW step 7) 


3 


Verify that ringback is present at UE A (prior to CFW step 10) 


4 


Answer the call at UE B (prior to CFW step 1 6) 


5 


Verify that voice can be exchanged in both directions (prior to CFW step 22) 


6 


Release call at UE A (prior to CFW step 22) 


7 


Verify that call is released at UE_B (prior to CFW step 25) 
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4.5.1.2 SIP Call Flow 

For a call with reliable provisional responses (lOOrel) and no SDP preconditions, the expected sequence is: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


1 




^ 








INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


2 




^ 








100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


3 






^ 






INVITE 


IMS A S-CSCF forwards INVITE to IMS B l-CSCF 


4 






^ 






100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


5 








^ 




INVITE 


IMS B P-CSCF forwards INVITE to UE B 


6 








^ 




100 Trying 


UE_B responds with a 100 Trying provisional 
response 


7 








^ 




180 Ringing 


UE_B responds to initial INVITE with 180 Ringing to 
indicate that it has started alerting 


8 






^ 






180 Ringing 


IMS B S-CSCF forwards 180 Ringing response to 
IMS A S-CSCF 


9 




^ 








180 Ringing 


IMS A P-CSCF forwards the 180 Ringing response 
to UE A 


10 




^ 








PRACK 


UE_A acknowledges the receipt of 180 response by 
sending PRACK 


11 






^ 






PRACK 


IMS A S-CSCF forwards PRACK to IMS B 
S-CSCF 


12 








^ 




PRACK 


IMS B P-CSCF forwards PRACK to UE B 


13 








^ 




200 OK 


UE B responds PRACK with 200 OK 


14 






^ 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


15 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


16 








^ 




200 OK 


UE_B responds INVITE with 200 OK to indicate that 
the call has been answered 


17 






^ 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


18 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


19 




^ 








ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 


20 






^ 






ACK 


IMS A S-CSCF forwards ACK to IMS B 
S-CSCF 


21 








^ 




ACK 


IMS B P-CSCF forwards ACK to UE B 


22 




^ 








BYE 


UE A releases the call with BYE 


23 






^ 






BYE 


IMS A S-CSCF forwards BYE to IMS B 
S-CSCF 


24 








^ 




BYE 


IMS B P-CSCF forwards BYE to UE B 


25 








^ 




200 OK 


UE B sends 200 OK for BYE 


26 






^ 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


27 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 
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4.5.2 UC 02: User-initiated call hold and resume 



4.5.2.1 



Description 



UE_A places an IMS VoIP call to UE_B. Once the media path is established, the originating user puts the call on hold, 
stopping the media stream. The originating user then resumes the call. The call flow path and node configuration for 
this use case corresponds to CF_M02-SS1-MT2. We assume reliable provisional responses (lOOrel) and no SDP 
preconditions. 

The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering): 



1 


Initiate an IMS VoIP call on UE A, addressed to UE B's SIP URI (prior to CFW step 1) 


2 


Verify that UE B rings (prior to CFW step 7) 


3 


Verify that ringback is present at UE A (prior to CFW step 10) 


4 


Answer the call at UE B (prior to CFW step 1 6) 


5 


Verify that voice can be exchanged in both directions (prior to CFW step 22) 


6 


Place call on hold at UE A (prior to CFW step 22) 


7 


Verify that voice can no longer be exchanged in both directions (prior to CFW step 25) 


8 


Resume call at UE A (prior to CFW step 28) 


9 


Verify that voice can be exchanged in both directions (prior to CFW step 31 ) 


10 


Release call at UE A (prior to CFW step 34) 


11 


Verify that call is released at UE_B (prior to CFW step 37) 
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4.5.2.2 SIP Call Flow with UPDATE 

The expected sequence: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


1 




^ 








INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


2 




^ 








100 Trying 


IMS_A P-CSCFW responds with a 100 Trying 
provisional response 


3 






^ 






INVITE 


IMS A S-CSCF forwards INVITE to IMS B l-CSCF 


4 






^ 






100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


5 








^ 




INVITE 


IMS B P-CSCF forwards INVITE to UE B 


6 








^ 




100 Trying 


UE_B responds with a 100 Trying provisional 
response 


7 








^ 




180 Ringing 


UE_B responds to initial INVITE with 180 Ringing to 
indicate that it has started alerting 


8 






^ 






180 Ringing 


IMS B S-CSCF forwards 180 Ringing response to 
IMS A S-CSCF 


9 




^ 








180 Ringing 


IMS A P-CSCF forwards the 180 Ringing response 
to UE A 


10 




^ 








PRACK 


UE_A acknowledges the receipt of 180 response by 
sending PRACK 


11 






^ 






PRACK 


IMS A S-CSCF forwards PRACK to IMS B 
S-CSCF 


12 








^ 




PRACK 


IMS B P-CSCF forwards PRACK to UE B 


13 








^ 




200 OK 


UE B responds to PRACK with 200 OK 


14 






^ 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


15 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


16 








^ 




200 OK 


UE_B responds to INVITE with 200 OK to indicate 
that the call has been answered 


17 






^ 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


18 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


19 




^ 








ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 


20 






^ 






ACK 


IMS A S-CSCF forwards ACK to IMS B 
S-CSCF 


21 








^ 




ACK 


IMS B P-CSCF forwards ACK to UE B 


22 




^ 








UPDATE 


UEA sends UPDATE message indicating media 
stream inactive (Call Hold) 


23 






^ 






UPDATE 


IMS A S-CSCF forwards UPDATE to IMS B 
S-CSCF 


24 








^ 




UPDATE 


IMS B P-CSCF forwards UPDATE to UE B 


25 








^ 




200 OK 


UE_B responds to UPDATE with 200 OK indicating 
media stream inactive 


26 






^ 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


27 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


28 




^ 








UPDATE 


UEA sends UPDATE message indicating media 
stream active (Call Resume) 


29 






^ 






UPDATE 


IMS A S-CSCF forwards UPDATE to IMS B 
S-CSCF 


30 








^ 




UPDATE 


IMS B P-CSCF forwards UPDATE to UE B 


31 








^ 




200 OK 


UE_B responds to UPDATE with 200 OK indicating 
media stream active 


32 






^ 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 
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Step 


Direction 


Message 


Comment 


33 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


34 




^ 








BYE 


UE A releases the call with BYE 


35 






^ 






BYE 


IMS A S-CSCF forwards BYE to IMS B 
S-CSCF 


36 








^ 




BYE 


IMS B P-CSCF forwards BYE to UE B 


37 








^ 




200 OK 


UE B sends 200 OK for BYE 


38 






^ 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


39 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 



4.5.2.3 SIP Call Flow with relNVITE 

The expected sequence: 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


1 




^ 








INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


2 




^ 








100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


3 






^ 






INVITE 


IMS A S-CSCF forwards INVITE to IMS B l-CSCF 


4 






^ 






100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


5 








^ 




INVITE 


IMS B P-CSCF forwards INVITE to UE B 


6 








^ 




100 Trying 


UE_B responds with a 100 Trying provisional 
response 


7 








^ 




180 Ringing 


UE_B responds to initial INVITE with 180 Ringing to 
indicate that it has started alerting 


8 






^ 






180 Ringing 


IMS B S-CSCF forwards 180 Ringing response to 
IMS A S-CSCF 


9 




^ 








180 Ringing 


IMS A P-CSCF forwards the 180 Ringing response 
to UE A 


10 




^ 








PRACK 


UE_A acknowledges the receipt of 180 response by 
sending PRACK 


11 






^ 






PRACK 


IMS A S-CSCF forwards PRACK to IMS B 
S-CSCF 


12 








^ 




PRACK 


IMS B P-CSCF forwards PRACK to UE B 


13 








^ 




200 OK 


UE B responds to PRACK with 200 OK 


14 






^ 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


15 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


16 








^ 




200 OK 


UE_B responds to INVITE with 200 OK to indicate 
that the call has been answered 


17 






^ 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


18 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


19 




^ 








ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 


20 






^ 






ACK 


IMS A S-CSCF forwards ACK to IMS B 
S-CSCF 


21 








^ 




ACK 


IMS B P-CSCF forwards ACK to UE B 


22 




^ 








INVITE 


UEA sends relNVITE message indicating media 
stream inactive (Call Hold) 


23 




^ 








100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 



ETSI 



58 



ETSI TS 186 011-2 V1.0.0 (2008-04) 



Step 


Direction 


Message 


Comment 


24 






^ 






INVITE 


IMS A S-CSCF forwards INVITE to IMS B 
S-CSCF 


25 






^ 






100 Trying 


IMS_B S-CSCF responds with a 100 Trying 
provisional response 


26 








^ 




INVITE 


IMS B P-CSCF forwards INVITE to UE B 


27 








^ 




100 Trying 


UE_B responds with a 100 Trying provisional 
response 


28 








^ 




200 OK 


UE_B responds to UPDATE with 200 OK indicating 
media stream inactive 


29 






^ 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


30 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


31 




^ 








ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 


32 






^ 






ACK 


IMS A S-CSCF forwards ACK to IMS B 
S-CSCF 


33 








^ 




ACK 


IMS B P-CSCF forwards ACK to UE B 


34 




^ 








INVITE 


UEA sends relNVITE message indicating media 
stream active (Call Resume) 


35 




^ 








100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


36 






^ 






INVITE 


IMS A S-CSCF forwards INVITE to IMS B 
S-CSCF 


37 






^ 






100 Trying 


IMS_B S-CSCF responds with a 1 00 Trying 
provisional response 


38 








^ 




INVITE 


IMS B P-CSCF forwards INVITE to UE B 


39 








^ 




100 Trying 


UE_B responds with a 100 Trying provisional 
response 


40 








^ 




200 OK 


UE_B responds to UPDATE with 200 OK indicating 
media stream active 


41 






^ 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


42 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


43 




^ 








ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 


44 






^ 






ACK 


IMS A S-CSCF forwards ACK to IMS B 
S-CSCF 


45 








^ 




ACK 


IMS B P-CSCF forwards ACK to UE B 


46 




^ 








BYE 


UE A releases the call with BYE 


47 






^ 






BYE 


IMS A S-CSCF forwards BYE to IMS B 
S-CSCF 


48 








^ 




BYE 


IMS B P-CSCF forwards BYE to UE B 


49 








^ 




200 OK 


UE B sends 200 OK for BYE 


50 






^ 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


51 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 



4.5.3 UC 03: S-CSCF initiated session release 



4.5.3.1 



Description 



UE_A places an IMS VoIP call to UE_B. Once the media path is established, the session is released by the originating 
network through a forced user de-registration at the HSS in IMS_A. The call flow path and node configuration for this 
use case corresponds to CF_M02-SS1-MT2. We assume provisional responses (lOOrel) and no SDP preconditions. 



ETSI 



59 



ETSI TS 186 011-2 V1.0.0 (2008-04) 



The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering): 



1 


Initiate an IMS VoIP call on UE A, addressed to UE B's SIP URI (prior to CFW step 1) 


2 


Verify that UE B rings (prior to CFW step 7) 


3 


Verify that ringback is present at UE A (prior to CFW step 10) 


4 


Answer the call at UE B (prior to CFW step 1 6) 


5 


Verify that voice can be exchanged in both directions (prior to CFW step 22) 


6 


Forced de-registration by IMS A (prior to CFW step 22) 


7 


Verify that call is released at UE_B (prior to CFW step 24) 



4.5.3.2 



Call Flow 



4.5.3.2.1 



Session release from originating network 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


1 




^ 








INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


2 




^ 








100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


3 






^ 






INVITE 


IMS A S-CSCF forwards INVITE to IMS B l-CSCF 


4 






^ 






100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


5 








^ 




INVITE 


IMS B P-CSCF forwards INVITE to UE B 


6 








^ 




100 Trying 


UE_B responds with a 100 Trying provisional 
response 


7 








^ 




180 Ringing 


UE_B responds to initial INVITE with 180 Ringing to 
indicate that it has started alerting 


8 






^ 






180 Ringing 


IMS B S-CSCF forwards 180 Ringing response to 
IMS A S-CSCF 


9 




^ 








180 Ringing 


IMS A P-CSCF forwards the 180 Ringing response 
to UE A 


10 




^ 








PRACK 


UE_A acknowledges the receipt of 180 response by 
sending PRACK 


11 






^ 






PRACK 


IMS A S-CSCF forwards PRACK to IMS B 
S-CSCF 


12 








^ 




PRACK 


IMS B P-CSCF forwards PRACK to UE B 


13 








^ 




200 OK 


UE B responds PRACK with 200 OK 


14 






^ 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


15 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


16 








^ 




200 OK 


UE_B responds INVITE with 200 OK to indicate that 
the call has been answered 


17 






^ 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


18 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


19 




^ 








ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 


20 






^ 






ACK 


IMS A S-CSCF forwards ACK to IMS B 
S-CSCF 


21 








^ 




ACK 


IMS B P-CSCF forwards ACK to UE B 


22 






^ 






BYE 


IMS_A S-CSCF releases the call towards the called 
user with BYE 


23 








^ 




BYE 


IMS B P-CSCF forwards BYE to UE B 


24 








^ 




200 OK 


UE B sends 200 OK for BYE 


25 






^ 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 
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Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


I 

M 
S 
B 


U 

E 
B 


26 




<- 








BYE 


IMS_A S-CSCF releases the call towards the calling 
user with BYE 


27 




■^ 








200 OK 


UE A sends 200 OK for BYE 



4.5.3.2.2 



Session release from terminating network 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


1 




^ 








INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


2 




^ 








100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


3 






^ 






INVITE 


IMS A S-CSCF forwards INVITE to IMS B l-CSCF 


4 






^ 






100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


5 








^ 




INVITE 


IMS B P-CSCF forwards INVITE to UE B 


6 








^ 




100 Trying 


UE_B responds with a 100 Trying provisional 
response 


7 








^ 




180 Ringing 


UE_B responds to initial INVITE with 180 Ringing to 
indicate that it has started alerting 


8 






^ 






180 Ringing 


IMS B S-CSCF forwards 180 Ringing response to 
IMS A S-CSCF 


9 




^ 








180 Ringing 


IMS A P-CSCF forwards the 180 Ringing response 
to UE A 


10 




^ 








PRACK 


UE_A acknowledges the receipt of 180 response by 
sending PRACK 


11 






^ 






PRACK 


IMS A S-CSCF forwards PRACK to IMS B 
S-CSCF 


12 








^ 




PRACK 


IMS B P-CSCF forwards PRACK to UE B 


13 








^ 




200 OK 


UE B responds PRACK with 200 OK 


14 






^ 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


15 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


16 








^ 




200 OK 


UE_B responds INVITE with 200 OK to indicate that 
the call has been answered 


17 






^ 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


18 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


19 




^ 








ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 


20 






^ 






ACK 


IMS A S-CSCF forwards ACK to IMS B 
S-CSCF 


21 








^ 




ACK 


IMS B P-CSCF forwards ACK to UE B 


22 






^ 






BYE 


IMS_B S-CSCF releases the call towards the calling 
user with BYE 


23 




^ 








BYE 


IMS A P-CSCF forwards BYE to UE B 


24 




^ 








200 OK 


UE A sends 200 OK for BYE 


25 






^ 






200 OK 


IMS A S-CSCF forwards 200 OK response to 
IMS B S-CSCF 


26 








^ 




BYE 


IMS_B S-CSCF releases the call towards the called 
user with BYE 


27 








^ 




200 OK 


UE B sends 200 OK for BYE 
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4.5.4 UC_04: P-CSCF initiated session release 
4.5.4.1 Description 

An internal message reports to the P-CSCF the loss of resource (e.g. radio resources). If a dialog initiation is started, but 
not yet established, then the P-CSCF will CANCEL the requests. If a UE_A Originated dialog is established then the 
call will be released by the P-CSCF (in IMS_A). If a UE_B Originated dialog is established then the call will be 
released by the P-CSCF (in IMS_A). The call flow path and node configuration for this use case corresponds to 
CF_M02-SS1-MT2. 

The test sequence typically associated with this use case when an established session is released is as follows (CFW 
step numbers refer the call flow step numbering): 



Initiate an IMS VoIP call on UE_A, addressed to UE_B's SIP URI (prior to CFW step 1) 



Verify that UE_B rings (prior to CFW step 7) 



Verify that ringback is present at UE_A (prior to CFW step 10) 



Remove cable, antenna or battery from UE_A (prior to CFW step 1 6/22) 



Verify that the call is terminated at UE_B (prior to CFW step 20/25) 
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4.5.4.2 



Call flow 



4.5.4.2.1 



Session establishment cancelled 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


1 




^ 








INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


2 




^ 








100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


3 






^ 






INVITE 


IMS A S-CSCF forwards INVITE to IMS B l-CSCF 


4 






^ 






100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


5 








^ 




INVITE 


IMS B P-CSCF forwards INVITE to UE B 


6 








^ 




100 Trying 


UE_B responds with a 100 Trying provisional 
response 


7 








^ 




180 Ringing 


UE_B responds to initial INVITE with 180 Ringing to 
indicate that it has started alerting 


8 






^ 






180 Ringing 


IMS B S-CSCF forwards 180 Ringing response to 
IMS A S-CSCF 


9 




^ 








180 Ringing 


IMS A P-CSCF forwards the 180 Ringing response 
to UE A 


10 




^ 








PRACK 


UE_A acknowledges the receipt of 180 response by 
sending PRACK 


11 






^ 






PRACK 


IMS A S-CSCF forwards PRACK to IMS B 
S-CSCF 


12 








^ 




PRACK 


IMS B P-CSCF forwards PRACK to UE B 


13 








^ 




200 OK 


UE B responds PRACK with 200 OK 


14 






^ 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


15 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


16 












LOSS 


Internal a message that resources for UE_A are not 
available 


17 






^ 






CANCEL 


IMS A sends CANCEL to IMS B 


18 






^ 






200 OK 


IMS B S-CSCF responds with a 200 OK 


19 








^ 




CANCEL 


IMS B sends CANCEL to UE B 


20 








^ 




200 OK 


UE B responds with 200 OK 


21 








^ 




437 Request Terminated 


UE B S-CSCF sends 437 Request Terminated to 
IMS B 


22 








^ 




ACK 


IMS B responds with ACK 


23 






^ 






437 Request Terminated 


IMS B sends 437 Request Terminated to IMS A 


24 






^ 






ACK 


IMS_A responds with ACK 
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4.5.4.2.2 



Session release from originating network 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


1 




^ 








INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


2 




^ 








100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


3 






^ 






INVITE 


IMS A S-CSCF forwards INVITE to IMS B l-CSCF 


4 






^ 






100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


5 








^ 




INVITE 


IMS B P-CSCF forwards INVITE to UE B 


6 








^ 




100 Trying 


UE_B responds with a 100 Trying provisional 
response 


7 








^ 




180 Ringing 


UE_B responds to initial INVITE with 180 Ringing to 
indicate that it has started alerting 


8 






^ 






180 Ringing 


IMS B S-CSCF forwards 180 Ringing response to 
IMS A S-CSCF 


9 




^ 








180 Ringing 


IMS A P-CSCF forwards the 180 Ringing response 
to UE A 


10 




^ 








PRACK 


UE_A acknowledges the receipt of 180 response by 
sending PRACK 


11 






^ 






PRACK 


IMS A S-CSCF forwards PRACK to IMS B 
S-CSCF 


12 








^ 




PRACK 


IMS B P-CSCF forwards PRACK to UE B 


13 








^ 




200 OK 


UE B responds PRACK with 200 OK 


14 






^ 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


15 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


16 








^ 




200 OK 


UE_B responds INVITE with 200 OK to indicate that 
the call has been answered 


17 






^ 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


18 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


19 




^ 








ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 


20 






^ 






ACK 


IMS A S-CSCF forwards ACK to IMS B 
S-CSCF 


21 








^ 




ACK 


IMS B P-CSCF forwards ACK to UE B 


22 












LOSS 


PDF or SPDF sends a message that resources are 
missing for UE_A 


23 






^ 






BYE 


IMS A P-CSCF sends BYE to IMS B 
S-CSCF 


24 








^ 




BYE 


IMS B P-CSCF forwards BYE to UE B 


25 








^ 




200 OK 


UE B sends 200 OK for BYE 


26 






^ 






200 OK 


IMS_B forwards 200 OK response to IMS_A 
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4.5.4.2.3 



Session release from terminating network 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


1 




^ 








INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that UE_A 
supports 


2 




^ 








100 Trying 


IMS_A P-CSCF responds with a 100 Trying 
provisional response 


3 






^ 






INVITE 


IMS A S-CSCF forwards INVITE to IMS B l-CSCF 


4 






^ 






100 Trying 


IMS_B l-CSCF responds with a 100 Trying 
provisional response 


5 








^ 




INVITE 


IMS B P-CSCF forwards INVITE to UE B 


6 








^ 




100 Trying 


UE_B responds with a 100 Trying provisional 
response 


7 








^ 




180 Ringing 


UE_B responds to initial INVITE with 180 Ringing to 
indicate that it has started alerting 


8 






^ 






180 Ringing 


IMS B S-CSCF forwards 180 Ringing response to 
IMS A S-CSCF 


9 




^ 








180 Ringing 


IMS A P-CSCF forwards the 180 Ringing response 
to UE A 


10 




^ 








PRACK 


UE_A acknowledges the receipt of 180 response by 
sending PRACK 


11 






^ 






PRACK 


IMS A S-CSCF forwards PRACK to IMS B 
S-CSCF 


12 








^ 




PRACK 


IMS B P-CSCF forwards PRACK to UE B 


13 








^ 




200 OK 


UE B responds PRACK with 200 OK 


14 






^ 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


15 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


16 








^ 




200 OK 


UE_B responds INVITE with 200 OK to indicate that 
the call has been answered 


17 






^ 






200 OK 


IMS B S-CSCF forwards 200 OK response to 
IMS A S-CSCF 


18 




^ 








200 OK 


IMS A P-CSCF forwards the 200 OK response to 
UE A 


19 




^ 








ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 


20 






^ 






ACK 


IMS A S-CSCF forwards ACK to IMS B 
S-CSCF 


21 








^ 




ACK 


IMS B P-CSCF forwards ACK to UE B 


22 












LOSS 


PDF or SPDF(in IMS_B) sends a message that 
resources are missing for UE B 


23 






^ 






BYE 


IMS A P-CSCF sends BYE to IMS B 
S-CSCF 


24 




^ 








BYE 


IMS B P-CSCF forwards BYE to UE B 


25 




^ 








200 OK 


UE B sends 200 OK for BYE 


26 






^ 






200 OK 


IMS_B forwards 200 OK response to IMS_A 
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4.5.5 UC_05: IMS message exchange between UEs in different networks 



4.5.5.1 Description 

The UE_A sends a MESSAGE to UE_B located in a different network. 

The test sequence typically associated with this use case when an established session is released is as follows (CFW 
step numbers refer the call flow step numbering): 



UE_A is requested to send a MESSAGE to UE_B (prior to CFW step 1 ) 



Verify that UE_B gets the MESSAGE (prior to CFW step 4) 



4.5.5.2 



Call flow 



Step 


Direction 


Message 


Comment 


U 

E 
A 


I 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


1 




^ 








MESSAGE 


UE A sends MESSAGE to IMS A 


2 






^ 






MESSAGE 


IMS A sends MESSAGE to IMS B 


3 








^ 




MESSAGE 


IMS A sends MESSAGE to UE B 


4 








^ 




200 OK 


UE B sends 200 OK to IMS B 


5 






^ 






200 OK 


IMS B sends 200 OK to IMS A 


6 




^ 








200 OK 


IMS A sends 200 OK to UE A 
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